Skip to content

Conversation

@Lash-L
Copy link
Collaborator

@Lash-L Lash-L commented Jun 15, 2023

Ok figured it out, the issue is with 24.0 of python-roborock.

Something with the valley timer and dnd timer being in the get_props.

Which in my opinion, we shouldn't be doing. If you look at how I do it in core, for entities outside of status, I have non-coordinated entities, these entities make the api call directly, that way if they aren't supported or if the user disables that entity, that call wont get made. Or If I update that entity, i.e. a switch on, I can just request the new status of that entity, rather than doing an entire coordinator refresh.

The issue stems with the valley timer, not sure why but that is causing all of the issues.

But for now I'm removing these from props as long as that is fine with you. And if I have time, I will try to rework the switches on homeassistant-roborock to match core as long as this is okay with you

@Lash-L
Copy link
Collaborator Author

Lash-L commented Jun 15, 2023

The cause of the error is that UnknownMethodException is being raised, but it is being treated as if it is a timeout, so it attempts to connect again

@Lash-L
Copy link
Collaborator Author

Lash-L commented Jun 15, 2023

also seems like we were scheduling a new ping everytime we reconnected, so the amount of pings grew everytime we reconnected.

@humbertogontijo
Copy link
Collaborator

What issues you are mentioning here?

@Lash-L
Copy link
Collaborator Author

Lash-L commented Jun 15, 2023

humbertogontijo/homeassistant-roborock#379

Any user who doesn't have valley timer - the version wasn't working

except RoborockException:
pass
if self.keep_alive_task is not None:
self.keep_alive_task.cancel()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed? The task will end after next line

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that call later returns a obj that can cancel the original callback, but when you call call_later it will run the action regardless of if the response gets overwritten.

I could be wrong though, I Didn’t extensively test

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. But this is cancelling it during execution. Right after ping was already called and next one is being scheduled
I think there is a cancel already when disconnected

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the case if the keep_alive_func is called by the call_later in keep alive func, but if keep_alive_func is called in async connect, then the existing keep alive task still exist and will continue to populate itself, but the new one will also be populating itself.

I just removed it for now though because I am not confident.

@humbertogontijo
Copy link
Collaborator

Yeah, using a non coordinated entity is the way to go

@Lash-L Lash-L requested a review from humbertogontijo June 16, 2023 01:57
Comment on lines +106 to +107
self.dnd_timer: DnDTimer | None = None
self.valley_timer: ValleyElectricityTimer | None = None
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is the best way, but I'm trying to avoid doing the coordinator, and rather than place it in device info, cause then I'd have to make a new function call on top of get_dnd_timer to update it, rather than just setting it here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about something similar. Having an object to hold all executed queries with evicting and caching based on GET / (SET / CHANGE) commands.
You can check them out in roborock_typing CacheableCommands

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that's nice and probably much better long term than this

@humbertogontijo
Copy link
Collaborator

I'll accept this since 1.0.7 is broken due to props not being compatible with all devices

@humbertogontijo humbertogontijo merged commit 2035af5 into Python-roborock:main Jun 16, 2023
@Lash-L
Copy link
Collaborator Author

Lash-L commented Jun 16, 2023

Ugh not sure why semantic release is still failing

@humbertogontijo
Copy link
Collaborator

Yeah. Maybe we need a commit message with current version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants