Closed pswid closed 2 years ago
Connection timeout take place if it can connect via IP, if IP is unavailable then it will timeout sooner and it is OS which takes care of that AFAIK.
Retrying is hard as I can't recognize wrong password vs network problem and if user type wrong password then I reconnection might end up with IP ban for xmpp connection.
What you could do right now is reload integration when network is up. And of course there is some problem with your network and I'd look to solve that
I’m having the same problem, and it wasn’t there in previous versions. Also, the gateway is running all the time, it is only a problem when HA restarts. So any networking issue would point to the HA OS network configuration not being ready - something that I do not have a lot of control over.
Any ideas if something changed regarding this?
Fastest way currently is to reload integration when network available. I'll try to figure it out for next release
In my case it's definitely not a network problem. KM200 gateway is connected to the same switch as the HA server and the integration is configured to use LAN HTTP communication (not cloud XMPP). Furthermore, there is no ping packet loss, so the gateway is available all the time and connection should be possible always, right? There is something wrong in the HA (or the integration itself) that causes connection problem during HA start-up.
What is the current timeout the integration waits for establishing connection? Could you increase it (just for test)?
Regarding in retrying in the background. Other integrations use this mechanism, so why don't you? Are you certain that there is no way to check if the connection was not established because of wrong password or just timeout? It's unbelievable that HA doesn't forward such info (server response) to the integration. Besides in case of http connection type, there is no need to worry about ban, because it's not possible, right? In addition, you can always set certain limit of attempts (e.g. 3 attempts every 30s). What do you think?
Docker in HA doesn't have network access soon enough. I don't know where problem is, I don't have it. Is ping working during startup from docker vm or are you talking ping from your PC? If second one then this won't tell us anything. Timeout is 10 secs, it's timeout for http response, not IP attempt. If IP is unavailable then it won't wait afaik.
I don't use this mechanism, because I don't have proper way to establish if it's network issue or password issue. I won't use different mechanisms for XMPP/HTTP because it would cause only problems. As I said, I'll try to figure it out for next release.
I'm using dedicated PC (Intel NUC with Celeron) exclusively for HA (Generic x86-64), not VM. There is probably no (easy) way to get direct access to docker to make ping test in such installations. I was pinging from other PC.
I am looking forward to the next version. Hope the problem can be solved.
I looked at debug LOG again and now I see that (this time only?) there was request timeout at the beginning (so 10s in not enough), but at the end it also shows "Found supported device" and loading proper database, so the connection was established after all, wasn't it?
2022-02-07 13:02:19 INFO (MainThread) [custom_components.bosch] Setting up Bosch component version 0.17.3.
2022-02-07 13:02:19 DEBUG (MainThread) [custom_components.bosch] Initializing Bosch integration.
2022-02-07 13:02:19 DEBUG (MainThread) [custom_components.bosch] Checking connection to Bosch gateway as 192.168.3.223.
2022-02-07 13:02:19 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /gateway/uuid
2022-02-07 13:02:34 DEBUG (MainThread) [bosch_thermostat_client.gateway.ivt] Can't fetch data for update_info Connection timed out for /gateway/uuid.
2022-02-07 13:02:34 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /system/bus
2022-02-07 13:02:37 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /gateway/versionFirmware
2022-02-07 13:02:38 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /system/brand
2022-02-07 13:02:39 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /system/info
2022-02-07 13:02:39 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /system/systemType
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.connectors.http] Sending GET request to /gateway/DateTime
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.gateway.ivt] Found supported device {'value': 'iCom_Low_NSC_v1', 'name': 'Enviline/Compress 6000/7000', 'type': 'NSC_ICOM_GATEWAY'} with id 172
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.gateway.ivt] Found supported device {'value': 'RC300', 'name': 'RC300/RC310/Nefit Moduline 3000', 'type': 'RC300_RC200'} with id 158
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.gateway.ivt] Using model iCom_Low_NSC_v1 as database schema
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.gateway.base] Found device {"value": "iCom_Low_NSC_v1", "name": "Enviline/Compress 6000/7000", "type": "NSC_ICOM_GATEWAY"}
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.db] Attempt to load database from file /usr/local/lib/python3.9/site-packages/bosch_thermostat_client/db/nsc_icom_gateway/040802.json
2022-02-07 13:02:40 DEBUG (MainThread) [bosch_thermostat_client.gateway.base] Loading database: NSC_ICOM_GATEWAY for firmware 04.08.02
2022-02-07 13:02:40 ERROR (MainThread) [custom_components.bosch] Cannot connect to Bosch gateway, host 192.168.3.223 with UUID: 918362517`
Immediately after adding integration (local http connection to the gateway), it works. Unfortunately after every HA restart it fails to start automatically displaying:
LOG shows nothing interesting, just "Cannot connect":
After HA finish starting I need to start the integration manually (disable and then enable). It's annoying.
As I see in LOG, some other integrations have also a problem with start in my installation (I suspect that database is too big or the computer too slow) but they eventually start fine because they are retrying in background:
Would you implement the same "retrying in background" mechanism to solve such problems, please? Temporary, could you increase connection timeout (is it now 10s?)? Maybe it will help...