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

Reconnecting sometimes fails for HmIp #191

Closed
eikowagenknecht opened this issue Jan 15, 2022 · 10 comments
Closed

Reconnecting sometimes fails for HmIp #191

eikowagenknecht opened this issue Jan 15, 2022 · 10 comments

Comments

@eikowagenknecht
Copy link
Contributor

eikowagenknecht commented Jan 15, 2022

Sometimes reconnecting fails when the CCU3 is rebooted, then it looks like this:

image

All HmIp devices failed, all Hm devices are there.

custom_component/hahomematic version (if applicable):
latest

Home Assistant version (if applicable):
latest

CCU version:
CCU3 with Raspberrymatic

To Reproduce
Steps to reproduce the behavior:

  1. Have HA running
  2. Reboot CCU

Expected behavior
Reconnection should not result in missing entities.

Restarting the integration fixes this as a workaround, but this should be handled automatically.

In the old integration there was a service homematic.reconnect which could be used to mitigate the problems. This service does not exist in the hahm.* namespace. A better solution would of course be if this wasn't even needed anymore.

Additional context
I've had a very similar bug in openHAB, see openhab/openhab-addons#8808 (comment) for the explanation of the addon developer there.

@SukramJ
Copy link
Owner

SukramJ commented Jan 16, 2022

What happens if you click on reload integration. That should be the equivalent to a service reload.

Please add logs

@SukramJ
Copy link
Owner

SukramJ commented Jan 16, 2022

Please give me a summary of the attached openhab issue. Why is this relevant?
hahomematic waits until a successful API PING (not icmp ping) do reinit the client.

@eikowagenknecht
Copy link
Contributor Author

Please give me a summary of the attached openhab issue. Why is this relevant?

It showed the same behaviour after reboot (HmIp not available while Hm is available), so I thought it might be the same issue. The most relevant finding is this:

This XML-RPC message appears because the CCU returns HTML code containing a message that it is not ready. Would be much better if it would return a correct error state ...

In combination with this:

hahomematic waits until a successful API PING (not icmp ping) do reinit the client.

it maybe would explain why your API PING succeeds even though the API is not really booted up correctly.

@eikowagenknecht
Copy link
Contributor Author

What happens if you click on reload integration. That should be the equivalent to a service reload.

Yes, reload integration fixed it.

Please add logs

Unfortunately after enabling the debug logging the error hasn't occurred for 5 CCU restarts in a row now which speaks for an error that could probably be dependent on the exact timing of the reconnection attempt . I'll keep restarting and hope that it fails again to privide better data :-)

@SukramJ
Copy link
Owner

SukramJ commented Jan 16, 2022

Yes, i guess the CCU is too slow for the current reconnect.

@SukramJ
Copy link
Owner

SukramJ commented Jan 16, 2022

Current config is a check interval of 30s, and reconnect immediately if check is successful again.
I will switch to less aggressive solution:
Check every 60s and wait 120s after successful connection check to reconnect.

@eikowagenknecht
Copy link
Contributor Author

eikowagenknecht commented Jan 16, 2022

I think the "wait 120s after successful connection check" will mostly fix it when there is no other way to reliably check if the service is running correctly yet. The correct time to wait would depend on the hardware the CCU is running on and maybe some other things like number of devices and/or programs, addons installed etc. :-/

Don't know why you would set the check interval from 30s to 60s though, this just increases the variation of the timespan (ccu_is_available to do_the_reconnect), doesn't it?

@SukramJ
Copy link
Owner

SukramJ commented Jan 16, 2022

I already planned to raise it to 60s before. Should be enough for a connection check.

@SukramJ
Copy link
Owner

SukramJ commented Jan 16, 2022

addressed in 0.23.0

@eikowagenknecht
Copy link
Contributor Author

Thanks. I have restarted about 20 times now and currently can't reproduce. I'll close this and reopen if I catch it another time.

@github-actions github-actions bot locked and limited conversation to collaborators Feb 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants