Litter-Robot integration is down

[natekspencer]

The problem

Whisker is changing the login and security endpoints and has disabled requests with HomeAssistant in the User-Agent header at this time.

What version of Home Assistant Core has the issue?

core-2023.8.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

Litter-Robot

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @tkdrob, mind taking a look at this issue as it has been labeled with an integration (litterrobot) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `litterrobot` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign litterrobot` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

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

[tkdrob]

The user agent can be set by the package when the author figures out a working one. When one is not given, I believe Home Assistant offers it's own.

[natekspencer]

As long as its not their intention to keep trying to thwart this. Thats why im curious if poster was told directly they are blocking the home assistant user agent or what. This is one mouse chase id rather avoid

Yes, I was told directly. They are aware of my library and have communicated with me in the past, so I reached out this morning once I determined what was happening and was told it was turned off "for now" while changes are being made. I've known that there was going to be changes to authentication for quite some time, though the exact changes and timeline have not been shared with me.

[mkanet]

I can confirm the same thing here. After all all that trouble getting the Litter-Robot integration working yesterday, its not available now.

I noticed an API error in my log today (thinking something was stuck that's residual from yesterday) I decided to remove my Litter-Robot integration and add it back. After I tried to add it back, it won't let me login with the correct credentials.

Can someone please post here as soon as there's news that Integration is back online?

[zimbrich]

I'm having the same connection issue. I have used this integration for over a year and had no issues. I have sent a support request to turn the API access back on. I am sure this is not going to change anything, but I figured if enough of us complain, maybe they might get the message.

[mkanet]

@zimbrich I did the same thing you did. It's important they know they have several customers who depend/prefer using the API over their regular mobile app.

[mhajda]

Very frustrating... I just re-built my HA instance due to a bunch of z-wave issues, and this was one of the last integrations to get back online. I have a frequently used automation that every time the cat sensor was tripped, I would wait 5 minutes and then turn on the exhaust fan in the laundry room.

[Unbeaten4350]

Very frustrating... I just re-built my HA instance due to a bunch of z-wave issues, and this was one of the last integrations to get back online. I have a frequently used automation that every time the cat sensor was tripped, I would wait 5 minutes and then turn on the exhaust fan in the laundry room.

That's one of the main points of having a smart home (and Home Assistant in particular), right? Home automation.

I've had my LR3 for about...9 years now? I've fixed almost every component in it over the years, and Whisker even sent out parts when it was out of warranty so I could rebuild it some more. (And because of all of this it's now a Connect model and doesn't have the shield.) I have 2 older cats that don't trigger the weight sensor any longer, so I've set up an automation to have it cycle if it hasn't over a particular time period...which isn't working at the moment, obviously.

If push comes to shove, doesn't the Connect have an ESP-based board?

[barrelltitor]

Will give them a ring as well. Might be worth everyone calling them so they understand that it's not just one random user who wants to use their litter robot this way.

I'm a bit pessimistic with companies doing this though. If they don't get it sorted, continuing on something like this might be the solution: https://github.com/smaslennikov/litter-controller

[mschwartz]

https://www.wireshark.org/

Easy enough to reverse engineer how the app is successful and the difference between it and the HA integration.

[talormanda]

I'd like to contact them as well, but with some intelligence when I make my complaint. What can I specifically say to them that will make sense so they understand?

[rjodwyer]

I think if they stand fast on this and don't open the API access back up then they will find a lot of LR going offline as we replace their boards with ESP32 and something like ESPHome to make it work again in HA.

We've got 3 of them and I run all the stats into Grafana, and use automations to trigger air purifiers at different times of the day, I was going as far as building a "toilet" sensor so if the offload was especially offensive then I could rotate it before the timer. Petty I know, but if I can automate it then why not.

[brianhansonxyz]

I have added my 2 cents to Whisker support urging them to support the restoration of this integration.

As a system administrator who maintains these kinds of endpoints myself, I know it is not much extra effort to keep these services working, and the sudden breaking of this type of integration is either indicative of a business decision purposefully harming product power users, or a indication of a sloppy development release cycle. If it is the former, it would be absurd that a premium smart home product is being anti consumer and disallowing integration into a larger smart home automation ecosystem. Heck, my bravia tv even has a well defined API for controlling it - you would think something like the litter robot, built as a premium product with the express mission statement of improving quality of life in a smart home would allow a premium user to use it as they see fit in their smart home. This is the way technology is going, well integrated smart homes are the future for all consumers.

I sincerely hope that what we are experiencing in terms of this integration being impacted by Whisker's API changes is done in good faith and not from an anti consumer standpoint.

[barrelltitor]

Does the integration already use this? https://github.com/natekspencer/pylitterbot

If the old api endpoints no longer work, but we can figure out the new ones, then we can sort this out. It's not a solution, the solution would be clear and proper deprecation + proper documentation, but at least it's something

This integration(previously on HACS) is the only reason I bought 2x littter bots + battery + etc, these were incredibly expensive and I seriously hope this is just a mistake from inexperience. This is not like Reddit, they already get their money from me buying their product, they don't give it to me for ads.

[Bl4cksus]

I have also opened a ticket with them to explain why HA can be an improvement to their product. I had it vacuum the robot area every 5th cycle via deebot, and give me notifications for the drawer nearing full via android tv and Alexa. I hope it’s just temporary, though I’m sure there will be other ways if not down the road…

[cmerkle]

I just submitted and angry ticket to LR support. I literally just finished setting up a LR card and a bunch of automations and then a few days later they broke the API. Pretty upset

[petervk]

Would it be helpful if more people contacted whisker support about this to complain?

Do we have any stats on how many people use this?

[ghxstxch]

Would it be helpful if more people contacted whisker support about this to complain?

Do we have any stats on how many people use this?

Any stats would likely be shown from this page, however many people, me included do not have reporting enabled.

Adding to the rest of the general conversation, I have also submitted a ticket to Whisker/Litter-Robot with my disappointment and urging them to reverse their decision. Might be just screaming into the void but I hope it helps.

[petervk]

I also filed a ticket with whisker support

[Waank1]

I have also submitted a ticket with Whisker, enquiring as to the status of the API, like mhajda I have several automations set up for the robot to include exhaust fan, air freshener and kitty poop notifications based on cat weight. I will share here what I found. On a side note, in the API, my last cat detected time/date is never in line with what is reported on the app. Is anyone else experiencing this? Have not opened a Git ticket, just wondering.....

[tomeralgai]

I suggest submitting tickets to Litter Robot using their contact us form

[natekspencer]

My two cents: I have no reason to believe Whisker is actively working to thwart this integration going forward. I do know they are migrating to OAuth 2.0 from their current auth/security token flow. And for whatever reason, they decided that they needed to block the HomeAssistant user-agent as a pre-step to completing it. I can only conjecture as to why they made this decision, but since the integration/API is reverse-engineered, I imagine it has something to do with limiting scope and errors so they can focus their efforts. They haven't made any attempts to rotate the api-key, nor have they sent a cease and desist letter, so I'm still hopeful.

While I won't discourage reaching out to support about the API, I'll also stop short of encouraging it, especially just to waste a rep's time. Again, this is a reverse-engineered API. So while the endpoint is public facing, it's not advertised nor supported outside of internal Whisker products, aka their official app. Simply turning it back on will just result in failure once the OAuth 2.0 migration is complete anyway (which I've no idea how soon or far off that is). It will also take some time to get that implemented into the library and, subsequently, into a HA release (one of my gripes about HA core integrations).

Also, don't mistake this as unwavering support of Whisker/Litter-Robot. While I love my robots and they have significantly made my life easier, I 100% would prefer a local, non-cloud based solution.

A workaround solution right now if you have access to the OS your HA instance is deployed on follows. Though again, it'll likely break once the migration is complete. To get it to work, locate the litterrobot/hub.py file and replace self.account = Account(websession=async_get_clientsession(hass)) with self.account = Account(). This should work if you had a previously working integration. If you deleted the integration and/or are trying to set up a new integration, you will also need to modify litterrobot/config_flow.py and replace account = Account(websession=async_get_clientsession(self.hass)) with account = Account(). You will have to restart HA after making either of those changes. And you will have to make those changes again if you update your HA core version at any time.

EDIT: the above works on a HA supervised install running on a raspberry pi. Due to the myriad of other install options available, I can't say for certain where your files will be located and can't provide support to find them.

[ghxstxch]

My two cents: I have no reason to believe Whisker is actively working to thwart this integration going forward. I do know they are migrating to OAuth 2.0 from their current auth/security token flow. And for whatever reason, they decided that they needed to block the HomeAssistant user-agent as a pre-step to completing it. I can only conjecture as to why they made this decision, but since the integration/API is reverse-engineered, I imagine it has something to do with limiting scope and errors so they can focus their efforts. They haven't made any attempts to rotate the api-key, nor have they sent a cease and desist letter, so I'm still hopeful.

While I won't discourage reaching out to support about the API, I'll also stop short of encouraging it, especially just to waste a rep's time. Again, this is a reverse-engineered API. So while the endpoint is public facing, it's not advertised nor supported outside of internal Whisker products, aka their official app. Simply turning it back on will just result in failure once the OAuth 2.0 migration is complete anyway (which I've no idea how soon or far off that is). It will also take some time to get that implemented into the library and, subsequently, into a HA release (one of my gripes about HA core integrations).

Also, don't mistake this as unwavering support of Whisker/Litter-Robot. While I love my robots and they have significantly made my life easier, I 100% would prefer a local, non-cloud based solution.

A workaround solution is relatively easy right now if you have access to the OS your HA instance is deployed on. Though again, it'll likely break once the migration is complete. To get it to work, locate the litterrobot/hub.py file and replace self.account = Account(websession=async_get_clientsession(hass)) with self.account = Account(). This should work if you had a previously working integration. If you deleted the integration and/or are trying to set up a new integration, you will also need to modify litterrobot/config_flow.py and replace account = Account(websession=async_get_clientsession(self.hass)) with account = Account(). You will have to restart HA after making either of those changes. And you will have to make those changes again if you update your HA core version at any time.

Thanks for this! I will attempt this ASAP and report back.

[talormanda]

My two cents: I have no reason to believe Whisker is actively working to thwart this integration going forward. I do know they are migrating to OAuth 2.0 from their current auth/security token flow. And for whatever reason, they decided that they needed to block the HomeAssistant user-agent as a pre-step to completing it. I can only conjecture as to why they made this decision, but since the integration/API is reverse-engineered, I imagine it has something to do with limiting scope and errors so they can focus their efforts. They haven't made any attempts to rotate the api-key, nor have they sent a cease and desist letter, so I'm still hopeful.

While I won't discourage reaching out to support about the API, I'll also stop short of encouraging it, especially just to waste a rep's time. Again, this is a reverse-engineered API. So while the endpoint is public facing, it's not advertised nor supported outside of internal Whisker products, aka their official app. Simply turning it back on will just result in failure once the OAuth 2.0 migration is complete anyway (which I've no idea how soon or far off that is). It will also take some time to get that implemented into the library and, subsequently, into a HA release (one of my gripes about HA core integrations).

Also, don't mistake this as unwavering support of Whisker/Litter-Robot. While I love my robots and they have significantly made my life easier, I 100% would prefer a local, non-cloud based solution.

A workaround solution is relatively easy right now if you have access to the OS your HA instance is deployed on. Though again, it'll likely break once the migration is complete. To get it to work, locate the litterrobot/hub.py file and replace self.account = Account(websession=async_get_clientsession(hass)) with self.account = Account(). This should work if you had a previously working integration. If you deleted the integration and/or are trying to set up a new integration, you will also need to modify litterrobot/config_flow.py and replace account = Account(websession=async_get_clientsession(self.hass)) with account = Account(). You will have to restart HA after making either of those changes. And you will have to make those changes again if you update your HA core version at any time.

What's the exact path for this? There are a lot of directories.

[natekspencer]

What's the exact path for this? There are a lot of directories.

There's also a number of ways to install HA, so it depends. I only know on my supervised install, in which I SSH'd into my RPi4 and did something like find / -wholename "*/litterrobot/hub.py" to find the location and then changed it.

[talormanda]

What's the exact path for this? There are a lot of directories.

There's also a number of ways to install HA, so it depends. I only know on my supervised install, in which I SSH'd into my RPi4 and did something like find / -wholename "*/litterrobot/hub.py" to find the location and then changed it.

I have it installed on proxmox and these are my directories:

[natekspencer]

I have it installed on proxmox and these are my directories:

This is the location on mine. Yours is bound to be different, but maybe it'll help to locate it. Otherwise your best bet is to find a way to run a search for a filename on proxmox.

/var/lib/docker/overlay2/ae9d8eabc86b5c9e717b39e1f0afa76122942da52e6d88f66de5d521e28102a9/diff/usr/src/homeassistant/homeassistant/components/litterrobot/hub.py

[imrj]

I suggest submitting tickets to Litter Robot using their contact us form

i just left another nasty support ticket....

[ljmerza]

Okay this needs to be locked. No need to be "nasty" when we don't even know what the company's plan is. Considering this is an unofficial API the company owes you nothing.

[talormanda]

I have it installed on proxmox and these are my directories:

This is the location on mine. Yours is bound to be different, but maybe it'll help to locate it. Otherwise your best bet is to find a way to run a search for a filename on proxmox.

/var/lib/docker/overlay2/ae9d8eabc86b5c9e717b39e1f0afa76122942da52e6d88f66de5d521e28102a9/diff/usr/src/homeassistant/homeassistant/components/litterrobot/hub.py

Very odd.

I am looking in /root/config/custom_components and I have absolutely no clue. There is no path anywhere named litterrobot and I have no files named hub.py. I did a search with WinSCP for *hub.py* and *hub* and no results came up. All my other custom installs are here because I see them:

But the litterrobot one is nowhere to be found. But...it is installed:

Also, I was guessing /root/config/components exists and it may be a core component which would be located there, but I don't see it as a directory.

Any advice?

[natekspencer]

Very odd.

This is not a custom component. Again, I don't use proxmox though, so no idea where core files get saved in it unfortunately.

[talormanda]

Very odd.

This is not a custom component. Again, I don't use proxmox though, so no idea where core files get saved in it unfortunately.

Yeah I know, I don't see any core component locations either.

[buckmelanoma]

The Litter Robot (3 at least) is based on the ESP8266. Sounds like it's time to explore a custom firmware for this thing.

[ChrisBaker97]

@talormanda on your setup, you're probably looking for /usr/src/homeassistant/homeassistant/components/litterrobot/hub.py

[talormanda]

@talormanda on your setup, you're probably looking for /usr/src/homeassistant/homeassistant/components/litterrobot/hub.py

Here is my directory path on HA when I SSH into HA. I don't have a path called /usr/src.

[ChrisBaker97]

Hi @natekspencer. Thanks for this info and for all your work on this project!

I had a working Litter Robot integration through sometime today (27 August), which seems a little odd, since this apparently broke a few days ago for most people. I had to restart Home Assistant (2023.7.3 Docker container) this evening while troubleshooting something entirely different, and I think that's when my Litter Robot issues began.

A workaround solution...

I edited hub.py as you suggested, but this doesn't seem to be having any effect. For good measure, I also edited config_flow.py, even though my integration was already installed and working, and again, no change. (I did this by docker exec -it homeassistant 'bash', editing the files in the running container using vi, then restarting Home Assistant from its web interface. Going back into the container, the files retained their modifications.)

Any insight on whether this is still a viable short-term workaround, or other suggestions?

[ChrisBaker97]

I don't have a path called /usr/src.

I see usr. You don't have src inside of usr?

[talormanda]

I don't have a path called /usr/src.

I see usr. You don't have src inside of usr?

Nope.

I even ran a find command for the folder and got nothing:

[talormanda]

I don't have a path called /usr/src.

I see usr. You don't have src inside of usr?

Nope.

I even ran a find command for the folder and got nothing:

[natekspencer]

@ChrisBaker97 The issue is with the login endpoint, which is hit on load of the integration. Once loaded, the websockets continue to receive data, which is why you didn't have any issues until a restart of HA occurred.

Docker containers usually have a source file system where the data is actually stored and loaded from. The problem you're seeing is that you're editing the temporary file that gets overwritten each time the docker instance is started back up, so you have to find where the actual source file is and make the change there.

[justinglavin]

I was able to authenticate and add my Litter Robot using the workaround with a brand new integration by updating hub.py and config_flow.py as instructed.

Hopefully we can figure out a long term solution. I wanted to set up an automation to send my Roborock vacuum into the laundry room where the Litter Robot is whenever a cat triggers it to keep things clean.

[ChrisBaker97]

Thanks @natekspencer. I'm actually not restarting the Docker container, just Home Assistant within the running container. The files aren't being overwritten, and I know my changes are being read because I made a typo the first time I edited hub.py and it threw an error on restart.

I think I saw elsewhere that you patched some code related to this issue. Is it possible that my running 2023.7.3 rather than 2023.8.4 or later is keeping the fix from working?

[natekspencer]

Thanks @natekspencer. I'm actually not restarting the Docker container, just Home Assistant within the running container. The files aren't being overwritten, and I know my changes are being read because I made a typo the first time I edited hub.py and it threw an error on restart.

I think I saw elsewhere that you patched some code related to this issue. Is it possible that my running 2023.7.3 rather than 2023.8.4 or later is keeping the fix from working?

Ahh yes, sorry I missed that part. You'll also need to adjust your manifest.json file then to use pylitterbot 2023.4.5 or later. There was a separate endpoint that was also deprecated

[barrelltitor]

For those having Docker issues, in your compose file mount just that file alone, e.g for linuxserver it's /lsiopy/lib/python3.11/site-packages/homeassistant/components/litterrobot/hub.py Here's the entire working file for anyone who needs it, so you can just mount it inside the container, maybe read only to make sure it doesn't get modified. This will only work if you didn't delete the integration previously:

https://gist.github.com/barrelltitor/55e7389b326787f6501d8d56ce386268

Example compose:

volumes:
  - /path/to/hub.py:/lsiopy/lib/python3.11/site-packages/homeassistant/components/litterrobot/hub.py:ro

Edit: Please DO NOT harass whisker. That is not the way to go. You can complain about an issue without being rude. Harassing them will just give them less reason to help out.

You can be politely outraged.

Edit2: @talormanda are you sure you're in the right place there?

If the integration is installed it's impossible for the files to not exist on the system. If it is installed, considering you're in a virtual environment, maybe the files are in some sort of image or handled in a way that doesn't make them directly accessible from the host OS, so you might need to ssh into your HA VM to find these files

[natekspencer]

Please DO NOT harass whisker. That is not the way to go. You can complain about an issue without being rude. Harassing them will just give them less reason to help out.

Precisely this. Being rude or inconsiderate will only potentially fester a non-working relationship with them.

[talormanda]

Apparently I had to go on the actual HA OS terminal and not through SSH. Once there, I was able to find 2 files with really long paths, and then I had to use vi editor to modify them. After doing this, it works. I wish there was an easier way to modify this.

cd /var/lib/docker/overlay2 find -path ‘*/litterrobot/hub.py’ vi /path/to/hub.py

Can someone break down why modifying this file works? Does it still communicate to Whisker, but with a different bit of code they aren't blocking? I would like to understand.

[natekspencer]

Can someone break down why modifying this file works? Does it still communicate to Whisker, but with a different bit of code they aren't blocking? I would like to understand.

To put it too simply, async_get_clientsession(hass) allows HA to manage the http client, cookies, connection pooling and cleanup of any code interacting with an external API. Basically, it's more efficient. But it also adds a default user-agent header as part of it (that's not a bad thing). This header is common amongst any interaction with an API. By changing the file, it passes the control on to the library I built, which doesn't have a header specified and has to manage it's own connection resources. Whisker specifically blocked requests that have the "HomeAssistant" user-agent header.

[talormanda]

Can someone break down why modifying this file works? Does it still communicate to Whisker, but with a different bit of code they aren't blocking? I would like to understand.

To put it too simply, async_get_clientsession(hass) allows HA to manage the http client, cookies, connection pooling and cleanup of any code interacting with an external API. Basically, it's more efficient. But it also adds a default user-agent header as part of it (that's not a bad thing). This header is common amongst any interaction with an API. By changing the file, it passes the control on to the library I built, which doesn't have a header specified. Whisker specifically blocked requests that have the "HomeAssistant" user-agent header.

Thanks. Is there a way they can still block this with the new method?

[natekspencer]

Thanks. Is there a way they can still block this with the new method?

Yes, this is a temporary workaround. Lots of APIs have even more strict controls around what must be present in the header to allow communication. Again though, I don't think they are trying to actively block HA permanently, but whilst they migrate. Once the backend authentication changes are complete, this will fail altogether until I can implement the new auth protocol. 🤞🏻

[talormanda]

Thanks. Is there a way they can still block this with the new method?

Yes, this is a temporary workaround. Lots of APIs have even more strict controls around what must be present in the header to allow communication. Again though, I don't think they are trying to actively block HA permanently, but whilst they migrate. Once the backend authentication changes are complete, this will fail altogether until I can implement the new auth protocol. 🤞🏻

Yikes. I depend on this integration a lot lol. Hopefully they see reason.