Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix device entities not showing up after reconnection #257

Conversation

DominikGebhart
Copy link

This fixes the issue of switch entities not becoming available after reconnecting my mss310EU plugs v6

This should fix missing availability after reconnection for any device that brings both entities that push state and that do not push state on their own

The issue with the mss310 plugs results from the _async_polling_callback never triggering a full device state update after a reconnection. I think this happens because the device has some power measurement entities that push updates right after rejoining, which leads to this.lastupdate being updated despite some entities state being missing and corresponding entities staying marked as unavailable.

Left as draft for now to discuss if there is maybe a better approach.

Re-querying Appliance.System.All when a device is recovering from being offline should not break things, however i cannot test this with other devices and this most likely also leads to querying full state twice on the first initialization..

I'd be grateful if someone more knowledgeable with the architecture can chime in.

… entities that do not push their state by themselves
@krahabb
Copy link
Owner

krahabb commented Feb 12, 2023

State refresh is always driving me mad! trying to optimize for both mqtt and http this is a dangerous game I know

Trying to set the context in which this happens: is your mss310 on MQTT ?
The idea in the patch you are suggesting is correct (getting the NS_ALL to be refreshed after a reconnection) but in my mind it should happen since the async_request_updates called when coming online should rightly do that in every scenario

EDIT:
Ok I got the issue, the context in which the async_request_updates is called is slightly modified from what's expected since it will be 'called later in the async context' and you're right: it will likely not throw any refresh (supposed you're on MQTT)

krahabb added a commit that referenced this pull request Feb 12, 2023
@DominikGebhart
Copy link
Author

Thank you for the quick reply.

Trying to set the context in which this happens: is your mss310 on MQTT ?

Yes indeed, my mss310 are connected to a local mosquitto mqtt server.

I left them configured on auto though since on mqtt it whill not reconnect at all (the mss310 probably wants some initialization at the start and this seems to not happen on mqtt-only, need to look into this another time though).

Ill ready this PR then, feel free to modify it if you have a better idea for the refresh

@DominikGebhart DominikGebhart marked this pull request as ready for review February 12, 2023 15:09
@DominikGebhart
Copy link
Author

DominikGebhart commented Feb 12, 2023

Thanks for the quick fix!
I close this PR since it is fixed the dev branch by re-querying all namespaces associated to the device when it gets online again

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.

None yet

2 participants