Not able to connect / connection failed

[shllg]

Hi there,

at first I want to thank for the work being done to make this integration possible. Unfortunately, I'm not able to make the integration work. After several hours trying, I'd like to ask for some support here.

Specs:

• HassOS 7.0
• HA 2021.12.2 (via Docker)
• Bosch Smart Home Controller and HA in the same network
• Multiple other systems/devices discovered inside the network by HA

Neither auto detection nor manual setup of SHC work.

I tried:

1. Adding it manually via UI
2. Adding it manually after adding the plugin into config/custom_components
3. Adding the config manually like

bosch_shc:
  host: X.X.X.X

No matter what, I'm not able to connect to the SHC.

The logs don't show any issues (or at least I did not find anything). For testing purposes, I entered some other IP or host domain. In those cases, HA raises an HTTPSConnectionPool error (Failed to get public information from SHC controller: HTTPSConnectionPool(host='X.X.X.X.', port=8446): Max retries exceeded with url: /smarthome/public/information....).

It does not show those errors when entering the actual SHC address.

Are there other ways to get more information/logs?

[armin-gh]

Perhaps a stupid question but you didn't mention it.... you did press the button on the controller and the LEDs started to blink?

You might see a bit more in the log after enabling logging for the component in configuration.yaml:

logger:
  default: warning
  logs:
    custom_components.bosch_shc: debug
    boschshcpy: debug

Not 100% sure about the name for the logger, boschshcpy does show some output on my test system, don't get much from the custom component

Armin

[shllg]

Hi @armin-gh
thank you for the fast response.

It's a valid question. But yes - I tried several ways (hold press while HA is running, hold press and reboot HA etc.). Didn't make any difference.

I pasted the config to configuration.yaml, restarted and tried again. I cannot see any new logs except of the normal "starting" / "stopping" stuff.

Again, if I choose e.g. another (wrong) IP address, errors appear in the logs.

---

Even with default: debug there is nothing shc related going on.

---

Update:

My fault - forgot that the ssh connection is via tmux -> not searchable via browser. Now I opened the log file directly. I'm getting output e.g.:

DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Bosch SHC [XX-XX-XX-XX-XX-XX]._http._tcp.local. ZeroconfServiceInfo(host='X.X.X.X', port=8443, hostname='shc107ef4.local.', type='_http._tcp.local.', name='Bosch SHC [XX-XX-XX-XX-XX-XX]._http._tcp.local.', properties={'_raw': {}}, _warning_logged=False)
....

The MAC address is correct.

Still I'm not able to set it up.

[shllg]

There are several more log entries. zeroconf seems to discover the service:

DEBUG (MainThread) [homeassistant.components.zeroconf] service_update: type=_hap._tcp.local. name=Bosch SHC 107ef4._hap._tcp.local. state_change=ServiceStateChange.Updated
DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Bosch SHC 107ef4._hap._tcp.local. ZeroconfServiceInfo(host='X.X.X.X', port=45090, hostname='shc107ef4.local.', type='_hap._tcp.local.', name='Bosch SHC 107ef4._hap._tcp.local.', properties={'_raw': {'c#': b'7', 'ff': b'2', 'id': b'37:70:B3:97:5A:9A', 'md': b'SMART_HOME_CONTROLLER', 'pv': b'1.1', 's#': b'13', 'sf': b'0', 'ci': b'2', 'sh': b'o+bs5w=='}, 'c#': '7', 'ff': '2', 'id': '37:70:B3:97:5A:9A', 'md': 'SMART_HOME_CONTROLLER', 'pv': '1.1', 's#': '13', 'sf': '0', 'ci': '2', 'sh': 'o+bs5w=='}, _warning_logged=False)

There are many DNSIncoming/DNSOutgoing logs per second, but I guess it's not important:

DEBUG (MainThread) [zeroconf] Sending to (224.0.0.251, 5353) via [socket 31 (('X.X.X.X', 5353))] (131 bytes #1) <DNSOutgoing:{multicast=True, flags=0, questions=[ptr[question,QU,in,_http._tcp.local.]], answers=[(record[ptr,in,_http._tcp.local.]=4500/4075,Samsung C2670 Series (SEC30CDA7A03E22)._http._tcp.local., 67315526.750433), (record[ptr,in,_http._tcp.local.]=4500/4373,Bosch SHC [XX-XX-XX-XX-XX-XX]._http._tcp.local., 67315526.750433)], authorities=[], additionals=[]}> as b'\x00\x00\x00\x00\x00\x01\x00\x02\x00\x00\x00\x00\x05_http\x04_tcp\x05local\x00\x00\x0c\x80\x01\xc0\x0c\x00\x0c\x00\x01\x00\x00\x0f\xeb\x00)&Samsung C2670 Series (SEC30CDA7A03E22)\xc0\x0c\xc0\x0c\x00\x0c\x00\x01\x00\x00\x11\x15\x00 \x1dBosch SHC [XX-XX-XX-XX-XX-XX]\xc0\x0c'...

[shllg]

First seconds of the log filtered by keyword "bosch"

https://gist.github.com/shllg/5086dd5305f3e928e15abeb81911a9d6

"bosch_shc" component is loaded but nevery logs anything. Homekit integration recognizes the Bosch controller but (as supposed to be) does not add it since it's already added to Homekit. zeroconf discovers the SHC.

[armin-gh]

It's a valid question. But yes - I tried several ways (hold press while HA is running, hold press and reboot HA etc.). Didn't make any difference.

And the LEDs on the controller still blinked when you entered the Hostname/IP and pressed the "Abschicken"-Button? Because otherwise the controller won't accept the new client.

not sure if it is related, a while ago I had a discussion over in the Home Assistant Community related to the Synology-Integration. It did not recognize the integration because of an orphaned entry for the device in "core.config_entries" in the .storage folder

you also might want to post your problem in Configuration Section of the Home Assistant Community.

Armin

[shllg]

And the LEDs on the controller still blinked when you entered the Hostname/IP and pressed the "Abschicken"-Button? Because otherwise the controller won't accept the new client.

Nope, won't stop blinking.

not sure if it is related, a while ago I had a discussion over in the Home Assistant Community related to the Synology-Integration. It did not recognize the integration because of an orphaned entry for the device in "core.config_entries" in the .storage folder

I checked every file in the storage folder. Found some references which were based on a FritzBox linking service. Removing those entries did not fix the issue.

[armin-gh]

I checked every file in the storage folder. Found some references which were based on a FritzBox linking service. Removing those entries did not fix the issue.

Anything in the core.config_entries with a "unique_id" matching the MAC of your Bosch-Controller?

Otherwise I'm lost here... sorry

[tschamm]

Thanks for reporting. I double-checked creating a connection with a clean HA config in my test setup. Works without any issue ...

My logger configuration:

logger:
  default: info
  logs:
    homeassistant.core: debug
    bosch_shc: debug
    boschshcpy: debug

The log should report this, when the password is wrong:

(SSL Error: HTTPSConnectionPool(host='192.168.x.x', port=8443): Max retries exceeded with url: /smarthome/clients (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:1129)')))).

The core config_entry should look somewhat like here:

            {
                "entry_id": "f7...",
                "version": 1,
                "domain": "bosch_shc",
                "title": "192.168.x.x",
                "data": {
                    "ssl_certificate": "/path_to_config/bosch_shc/bosch_shc-cert.pem",
                    "ssl_key": "/path_to_config/bosch_shc/bosch_shc-key.pem",
                    "host": "192.168.x.x",
                    "token": "G24...:xx-xx-xx-xx-xx-xx",
                    "hostname": "xx-xx-xx-xx-xx-xx"
                },
                "options": {},
                "pref_disable_new_entities": false,
                "pref_disable_polling": false,
                "source": "user",
                "unique_id": "xx-xx-xx-xx-xx-xx",
                "disabled_by": null
            }

[tschamm]

Can you post information on HA system health? see Configuration -> Configuration -> Info.

If you are using docker, please make sure to add --net=host to the options.

[shllg]

Anything in the core.config_entries with a "unique_id" matching the MAC of your Bosch-Controller?

No -.-

Otherwise I'm lost here... sorry

I'm very grateful for your efforts! @armin-gh

The log should report this, when the password is wrong:

@tschamm Thank you for your reply. Which password are you referring to? I changed the logger config and tried again - without success. It always fails at the "asking for Host" part. Again - entering the right IP does not produce any logs. Entering a wrong address (to test if logging works) will log Failed to get public information from SHC controller: HTTPSConnectionPool. So the failure reason when connecting to the SHC is not logged.

Can you post information on HA system health? see Configuration -> Configuration -> Info.

If you are using docker, please make sure to add --net=host to the options.

Well I'm running the the HAOS. It's a very basic and customized Linux as far as I can see. I need to look how they spin up docker and if it would be overwritten when updating. Need to do some research for that.

[tschamm]

Can you test the following on a machine with python3.9 and boschshcpy installed?

You can do this directly from your home assistant command line

bash$ docker exec -i -t homeassistant python3.9
>>> from boschshcpy import SHCRegisterClient
>>> client = SHCRegisterClient(controller_ip="192.168.x.x", password="your_shc_password")
>>> client.register(client_id="test", name="test")

This should result in a json result including a token, a cert and a key.

[shllg]

Since the linux is pretty downsized, I need to use the OpenSSH plugin for HA which basically logs me in into HA container directly - I guess...

---

First try of from boschshcpy import SHCRegisterClient resulted in missing package. So there is no package boschshcp installed. Shouldn't it be automatically installed due to dependencies?

---

I installed everything to run your test code above:

apk add libffi-dev gcc python3-dev musl-dev
python3.9 -m ensurepip --upgrade
pip3.9 install boschshcpy cryptography

Afterwards, your code returned JSON including token, cert and key.

---

After restarting HA from the web interface, I still could not add the integration (same situation like before).

[shllg]

Ok I provided wrong information - sorry about that. Didn't know how the ssh addon works. Seems like it spins up a dedicated container with shared folder structure. It seems not to be the actual HA container. That's why importing default HA py resources won't work too and the installation steps above are required.

At least we know, that the boschshcpy call works from inside the environment.

[shllg]

Logged in into the machine and container directly. The code works in homeassistant container and returns the token etc.

[tschamm]

That at least sounds good. Can you check what happens if you try to configure the component using a wrong password?
I will have a look into the code what the issue could be...

[shllg]

How can I provide the information via config? Didn't find it in the readme.

At the UI, I won't get to that point.

[tschamm]

Are you using the custom component?
Configuration -> Devices & Integrations -> Add integration -> bosch shc -> "Enter the correct IP address" -> "Enter a wrong password"
You should at least see some messages in the log, and a warning that the password was either wrong or the SHC was not in authentication mode.

[shllg]

😅 well as stated above, I never get to that point. It always fails after entering the host (result is the screen on my original message).

I tried the included version but also checked out the repo and symlinked the custom_components/bosch_shc into the config folder. Both do not work.

[shllg]

I tried to find out a bit more - am not very profound with Python - so it takes a while. The error message (cannot_connect) is generated here:

config_flow.py:106

        try:
                self.info = info = await self._get_info(host)
            except SHCConnectionError as err:
                errors["base"] = "cannot_connect"

Seems like to be the call self.hass.async_add_executor_job inside _get_info.

Inside get_info_from_host the line information = session.mdns_info() fails.

[shllg]

Added a logging statement to that row. The result:

[tschamm]

That's odd. What version of the SHC controller are you using? Something like 10.4.2284-22213 or -22214?
It seems the keyword shcIpAddress is not available, this should be provided via the public information. you can use either postman, or display the information via

wget https://192.168.x.x:8446/smarthome/public/information --no-check-certificate

If you have an older version installed, I suggest to update the SHC controller. If this won't work, I need to write a workaround for devices not providing an ip address.

[shllg]

The controller version is 10.4.2284-22213.

A strange thing is, that inside the SHC app, "IP address of the Smart Home Controller" is empty always. The SHC gets a fixed IP from the DHCP. The system works properly - with Homekit too.

Resetting the controller did not solve anything.

The information api call returns:

{
  "apiVersions": [
    "2.6"
  ],
  "softwareUpdateState": {
    "@type": "softwareUpdateState",
    "swUpdateState": "NO_UPDATE_AVAILABLE",
    "swUpdateLastResult": "UPDATE_SUCCESS",
    "swUpdateAvailableVersion": "",
    "swInstalledVersion": "10.4.2284-22213",
    "swActivationDate": {
      "@type": "softwareActivationDate",
      "timeout": 604800000
    },
    "automaticUpdatesEnabled": true
  },
  "macAddress": "xx-xx-xx-xx-xx-xx",
  "claimed": true,
  "country": "DEU",
  "tacVersion": "DEU-12",
  "clientIds": [
    "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
  ],
  "featureToggles": {
    "app-store-rating.ios": true,
    "protect-plus.fuchsia": true,
    "homekit-twinguardvoc": false,
    "psm.pc.pairing": true,
    "smart-light.pairing": true,
    "homekit-bwth": false,
    "wls.pairing": true,
    "shading.advance.menu": true,
    "analytics.toggle.bronze": true,
    "outdoor-siren.pairing.ebony": true,
    "smlo.release": true,
    "app-store-rating.android": true,
    "homekit-plugcompact": false,
    "cloud.tokenvalidation": true
  },
  "connectivityVersions": [
    {
      "name": "claiming",
      "minVersion": 1,
      "maxVersion": 1
    },
    {
      "name": "noncePairing",
      "minVersion": 1,
      "maxVersion": 1
    },
    {
      "name": "buttonPairing",
      "minVersion": 1,
      "maxVersion": 1
    }
  ]
}

As different examples on the net show, there should be the shcIpAddress field. But it is not... seems like Bosch removed it.

[tschamm]

Thanks for confirming that. I have never experienced this, I will see if I can provide a fix for this before Christmas.

Maybe it would be worth opening a ticket in the Bosch API repo. Would be interesting what caused this.

[shllg]

As stated in the bosch-shc-api-docs project, the field is only omitted, if the controller cannot determine it's own IP address (which is strange since communications work). I created a ticket directly at the Bosch support page.

[armin-gh]

While you wait for a response from Bosch-Support... anything special you are using as DHCP-Server?
Really odd that the Controller responds to the IP-Address, but does not show the same Address in the App or in the JSON retrieved via the API.
Also wondering what role Homekit is playing here... the MAC shown for the IP in the output of "arp -a" matches the MAC for the Controller? Should start with 64:da:a0

Armin

[tschamm]

I just pushed a new pre-release 0.4.22 which you can install via HACS, which fixes a missing IP address in the public information. @shllg Can you test the pre-release and provide a short hint, if this works for you?

[shllg]

Sorry for the late reply. Vodafone kicked us out of the internet for multiple days -.-

@tschamm I'm so grateful - thank you very much! It is working. With the new code, the zeroconf worked. Just needed to enter the password and all devices are connected!

@armin-gh No special DHCP. I don't expect any response from Bosch soon... But yes, it's pretty odd. MACs are correct. Everything is detected. But the controller does not recognize it's own IP. No problem with Ikea or Philips. So I guess it's a Bosch related issue.

---

I need to thank you again for the awesome support. Especially since everybody got enough to do before and over Christmas.