Bosch Radiator Thermostat II

Not so long time ago Bosch presented new ZigBee based Radiator Thermostat II.

Unfortunately this device is not supported yet. Also it seems there is a pairing problem - cluster information is not visible in deCONZ.

Probably device requires to use install code to pair. The code is printed on device battery cover next to Zigbee EUI-64 code.

Link to GitHub issue:

There is a similar problem with another Bosch ZigBee based device:

2 Likes

No news?

Anyone has any experience with these, yet? The GitHub topic mentions that this may only work unreliably…?

I have one of these. Can someone explain to me how to connect These in phoscon using install codes?

  1. Provide the install code via the deconz REST API. I use Postman for this but there are many options for API tools. Ensure that you provide the full length of the code (36 characters without hyphens or blanks).
  2. In Phoscon, scan for a new sensor and put the battery in/remove the protective lid.
  3. In the Deconz GUI and in this case also in Phoscon, the device appears.

The Thermostat II works fine for me so far.

1 Like

Many thanks for your helpful post. How did you determine the MAC Address of the device?
There is only a Zigbee EUI-64 printed on the battery cover.

The EUI-64 corresponds to the MAC address.

1 Like

Thanks a lot! Scanning as a sensor and using the EUI-64 (Capital letters, seems to be case sensitive) did the trick.

Hi All,

I’m running a ConBee II on a Raspberry Pi 4, Ubuntu Server. Using Gateway Version 2.24.2 and Firmware 26780700.

I ran a PUT request as follows:
http://192.168.178.135:8090/api/XXXXXXXXXX/devices/YYYYYYYYYYYYYYYY/installcode

with JSON raw input:

{
  "installcode": "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"
}

I get a 503, “Service Unavailable”:

[
  {
    "error": {
      "address": "/devices",
      "description": "internal error, failed to calc mmo hash, occured",
      "type": 901
    }
  }
]

ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ is the 36 characters install code (without hyphens). In the battery lid, it’s called “Install Code”. XXXXXXXXXX is my 10 chars long API key. YYYYYYYYYYYYYYYY is the 16 characters long ZigBee EUI-64. I’ve read the QR code and found it to be a 95 chars long string where ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ are the last 36 chars and YYYYYYYYYYYYYYYY starts after the first 40 chars. This way, I’ve triple-checked that there’s no typo in my inputs. Could you please guide me in the right direction here? Thanks.

Hm, that shouldn’t be… On which OS is your deconz running? Assuming you entered the device MAC without colons, the length of the install code is fine (16 Bytes code + 2 Bytes CRC = 18 while a Bytes has 2 chars).

I have a test script to calculate some test hashes and that runs fine with the expected output :thinking:

Hi Swoop,

Installation is based on deconz_2.24.2-debian-buster-stable_arm64.deb under Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-1042-raspi aarch64).

The below is the content of a little test script. Just set your API key, IP and port, put it into an executable script file and run it (requires jq command to be installed).

#!/bin/sh

HOST="127.0.0.1:8080"
APIKEY="123456789"

# 6 byte IC test

# 83FED3407A93
# 83FED3407A932B70

# HASH CD4FA064773F46941EC986C09963D1A8

echo "--- 6-bytes -----------"

curl -s -XPUT -H "Content-type: application/json" -d '{"installcode": "83FED3407A932B70"}' "${HOST}/api/${APIKEY}/devices/999/installcode" \
	| jq

echo  "[VERIFY] HASH MUST BE CD4FA064773F46941EC986C09963D1A8"

# 8-bytes IC test

# 83FED3407A939738
# 83FED3407A939738C552

# HASH A833A77434F3BFBD7A7AB97942149287
echo "--- 8-bytes -----------"

curl -s -XPUT -H "Content-type: application/json" -d '{"installcode": "83FED3407A939738C552"}' "${HOST}/api/${APIKEY}/devices/999/installcode" \
	| jq

echo  "[VERIFY] HASH MUST BE A833A77434F3BFBD7A7AB97942149287"

# 12-bytes IC

#      83FED3407A939723A5C639FF
#      83FED3407A939723A5C639FF4C12

echo "--- 12-bytes ----------"

curl -s -XPUT -H "Content-type: application/json" -d '{"installcode": "83FED3407A939723A5C639FF4C12"}' "${HOST}/api/${APIKEY}/devices/999/installcode" \
	| jq
	
echo  "[VERIFY] HASH MUST BE 58C1828CF7F1C3FE29E7B1024AD84BFA"

# 16-bytes IC

# 83FED3407A939723A5C639B26916D505
# 83FED3407A939723A5C639B26916D505C3B5
echo "--- 16-bytes ----------"

curl -s -XPUT -H "Content-type: application/json" -d '{"installcode": "83FED3407A939723A5C639B26916D505C3B5"}' "${HOST}/api/${APIKEY}/devices/999/installcode" \
	| jq
	
echo  "[VERIFY] HASH MUST BE 66B6900981E1EE3CA4206B6B861C02BB"

After update to the latest docker image I have the same error when trying to add install code (901, failed to calc mmo hash). Before update it was working. Results of running test script:

$ ./test.sh
--- 6-bytes -----------
[
  {
    "error": {
      "address": "/devices",
      "description": "internal error, failed to calc mmo hash, occured",
      "type": 901
    }
  }
]
[VERIFY] HASH MUST BE CD4FA064773F46941EC986C09963D1A8
--- 8-bytes -----------
[
  {
    "error": {
      "address": "/devices",
      "description": "internal error, failed to calc mmo hash, occured",
      "type": 901
    }
  }
]
[VERIFY] HASH MUST BE A833A77434F3BFBD7A7AB97942149287
--- 12-bytes ----------
[
  {
    "error": {
      "address": "/devices",
      "description": "internal error, failed to calc mmo hash, occured",
      "type": 901
    }
  }
]
[VERIFY] HASH MUST BE 58C1828CF7F1C3FE29E7B1024AD84BFA
--- 16-bytes ----------
[
  {
    "error": {
      "address": "/devices",
      "description": "internal error, failed to calc mmo hash, occured",
      "type": 901
    }
  }
]
[VERIFY] HASH MUST BE 66B6900981E1EE3CA4206B6B861C02BB

It feels that there’s something odd with the SSL libraries. Asked for a 2nd opinion.

I think it’s related (and perhaps fixed) with following PR from yesterday?

Would be happy to test. But no fix for ARM64 yet if interpret right?

Guys, that stuff is annoying. I hopped on the ConBee train as I liked the product being from Germany, development taking place on GitHub, bla. I‘m running my set-up for approx. two years now and, for various reasons, it has been a pain in the bottom for most of the time. I‘ve recently switched from ConBee II to ConBee III. Today, I found that most of my sensors are not recognized anymore. Meanwhile, my Bosch thermostats are attracting dust and can’t be connected to ConBee.

I‘ve recently switched from ioBroker to Home Assistant and I felt a big relief. What a valuable piece of software. I will sell my ConBees and move to a competitor‘s ZigBee dongle, hoping to find another eureka moment.

1 Like

I switched to a SONOFF Zigbee Gateway ZBDongle-E, my thermostats work flawlessly with it. I hate to say that but I had to change the stick.

Hello there,
I waited for the 2.25.0 update to try again but I still get the same error.

I used a query that was working with some older version of deconz but get the 503 with the hash failure.

Yep, same here.

image