romedtino / simple-wyze-vac

Home Assistant Custom Component for Wyze Vacuum
48 stars 8 forks source link

[BUG] After removing and re-adding integration, TypeError: unsupported operand type(s) for -: 'int' and 'NoneType' #55

Closed SpartanTech closed 1 year ago

SpartanTech commented 1 year ago

Describe the bug I moved my vacuum from my work to family account and after deleting and re-adding the integration, it fails to add now. I get a TypeError, unsupported errand type. It was working fine today before I removed the integration to add the new account. Tried with F2A email, F2A auth token, and F2A disabled. I don't believe the firmware was auto-updated, it didn't tell me if so

To Reproduce Steps to reproduce the behavior:

  1. Remove integration
  2. Re-Add integration
  3. Will enable the integration successfully but fails failed to load, check error logs
  4. Logs say Error setting up entry
  5. vacuums.py, TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

Expected behavior Successful add just like right before.

Screenshots Screenshot 2023-04-04 182522

Simple Wyze Vac Version 1.82

Wyze Vacuum Firmware Version 1.6.306

Home Assistant Version 2023.3.6

Additional context

romedtino commented 1 year ago

1.6.202 is the max I can personally support in regards to Wyze Firmware Version. I would need someone else who has 1.6.306 to do the testing to fix this sort of issue. And I don't know if the error you see is the only one as well.

It seems on 1.6.306, the variable self.usage is no longer populated. This might be better off as an issue to file against https://github.com/shauntarves/wyze-sdk to either capture cases where self._usage is None and convert it to an int prior to subtracting or guarantee it to be an int? Or dig out the correct new way to get usage value out

If you're savvy enough, you can remote into your Home Assistant instance, go to /usr/local/lib/python3.10/site-packages/wyze_sdk/models/devices/vacuums.py and change line 970 from

self.type.max_hours - self.usage

to

self.type.max_hours - int(self.usage or 0)

Then reboot HA and see if Simple Wyze Vac gets further in the initialization process. But keep in mind, your vacuum will just always return max hours since it could not actually query actual usage.

SpartanTech commented 1 year ago

1.6.202 is the max I can personally support in regards to Wyze Firmware Version. I would need someone else who has 1.6.306 to do the testing to fix this sort of issue. And I don't know if the error you see is the only one as well.

It seems on 1.6.306, the variable self.usage is no longer populated. This might be better off as an issue to file against https://github.com/shauntarves/wyze-sdk to either capture cases where self._usage is None and convert it to an int prior to subtracting or guarantee it to be an int? Or dig out the correct new way to get usage value out

If you're savvy enough, you can remote into your Home Assistant instance, go to /usr/local/lib/python3.10/site-packages/wyze_sdk/models/devices/vacuums.py and change line 970 from

self.type.max_hours - self.usage

to

self.type.max_hours - int(self.usage or 0)

Then reboot HA and see if Simple Wyze Vac gets further in the initialization process. But keep in mind, your vacuum will just always return max hours since it could not actually query actual usage.

That's what I thought, it didn't notify me it updated, I guess it must have updated since the last time I added the integration.

Thanks a bunch for the quick reply. Musician for the last 10 years, but I graduated computer science, so as long as I'm pointed in the right direction I can usually handle it myself 🤣, thanks for the nudge. I'll take a look at that file when I get home.

If you need any data from something specific, I can provide that as well no problem.

SpartanTech commented 1 year ago

1.6.202 is the max I can personally support in regards to Wyze Firmware Version. I would need someone else who has 1.6.306 to do the testing to fix this sort of issue. And I don't know if the error you see is the only one as well. It seems on 1.6.306, the variable self.usage is no longer populated. This might be better off as an issue to file against https://github.com/shauntarves/wyze-sdk to either capture cases where self._usage is None and convert it to an int prior to subtracting or guarantee it to be an int? Or dig out the correct new way to get usage value out If you're savvy enough, you can remote into your Home Assistant instance, go to /usr/local/lib/python3.10/site-packages/wyze_sdk/models/devices/vacuums.py and change line 970 from

self.type.max_hours - self.usage

to

self.type.max_hours - int(self.usage or 0)

Then reboot HA and see if Simple Wyze Vac gets further in the initialization process. But keep in mind, your vacuum will just always return max hours since it could not actually query actual usage.

That's what I thought, it didn't notify me it updated, I guess it must have updated since the last time I added the integration.

Thanks a bunch for the quick reply. Musician for the last 10 years, but I graduated computer science, so as long as I'm pointed in the right direction I can usually handle it myself 🤣, thanks for the nudge. I'll take a look at that file when I get home.

If you need any data from something specific, I can provide that as well no problem.

I had to edit home assistant directly via docker, but I found the file and modified it. It works just perfect now, that was the exact issue!

Do you know what would reset the file change? Would a wise vacuum update, a home assistant update, or system reboot reset that file?

SpartanTech commented 1 year ago

No one happens to have any experience with docker modifications do they? After I edited the file, home assistant updated and removed the edit. I'm guessing I need to edit a different file or clonr my own sdk? What's the easiest way for that line change to be persistent

romedtino commented 1 year ago

Unfortunately whenever HA updates, it will essentially pull fresh copies of the addons and all that. So everytime HA updates, you would have to change it. It should at least persist on reboots.

So did that change work for you? With that workaround, have you tried to see if the rest of the functionality is there (start vac/pause vac/go dock/etc.)? If so, I wouldn't mind updating the version of wyze-sdk I use to add that int check. Let me know 👍

SpartanTech commented 1 year ago

Ah I see. Yeah, editing the file allows the integration to load and show the map, but other things fail. Starting, Stopping, and Docking commands work, but show Error on Home Assistant (as if it didnt work). Polling also gives errors when enabled. So in short, sends the commands ok seems like but room selection cleaning and receiving data back shows an Error on home assistant side. image

I can try to investigate on my own and give a log or something that might help. If you have any nudges or tips on where to look or what to enable to view the actual debug log, let me know!

HA Log shows: image

romedtino commented 1 year ago

The error states returned should be addressed in this release - https://github.com/romedtino/simple-wyze-vac/releases/tag/1.8.3

(you can try it if you enable show beta releases on HACS -> Simple Wyze Vac)

Issue was Wyze added new names for states and they were not accounted for.