Cosmo CRTDW Thermostat - encryption

[Phil_123]

Hello everyone,
in our home, we have this thermostats installed: Cosmo CRTDW which apparently can be connected via zigbee.
Now I would like to use it in conjunction with home assistant. But before I get a zigbee connector I would like to know if I can connect to it in principle. I have the following questions:

• I could not find a “Cosmo” integration, is the Zigbee protocoll so universal that I can connect to it anyway? Or is this specific to each thermostat?
• The datasheet say that it uses “ZigBee protocoll implemented security (ISO-27001 and SSAE16 / ISAE 3402 Typ II - SOC 2-Certification” and that the connection is AES encrypted. Is this a problem? Are there any other integrations which support encrypted Zigbee communication?

If there is no integration available, I would be open to giving it a try in programming it myself. However I have no experience (as you might guess from my post here) about Zigbee and developing integrations in HA…

Best,
Phil

P.S. If anyone is interested, the datasheet can be found on this site, you have to search for “CRTDW”. Unfortunately I cannot upload the pdf file directly (it is in german anyway)

[Hedda]

The short answer is that you could try using most Zigbee devices via either the native ZHA (Zigbee Home Automation) integration or you can use a third-party stand-alone gateway/hub application like Zigbee2MQTT (which then integrates via MQTT) or Phoscon/deCONZ (which integrates via deCONZ integration).

Most Zigbee thermostats, however, use customized firmware configurations to expose different Zigbee clusters and attributes so will usually require that the developers of those integrations/applications write some parsing/converter/translator/quirk code for those existing integrations/applications before so that it can work perfectly in them, that is unless those integrations/applications already have the support that specific device since previosuly.

Read this → https://www.home-assistant.io/integrations/zha#knowing-which-devices-are-supported

and this → https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling

for developers → https://github.com/zigpy/zha-device-handlers/blob/f9b96f1d6b5aea3c9e4ca8b816c5f96b43d58fcf/README.md

Regardless you will need a Zigbee Coordinator adapter that is compatible with the one you can to use. Note there that the official Home Assistant SkyConnect USB Stick available now for pre-order is only stable/mature in the ZHA integration today, while ConBee II USB adapter is compatible with all of those integrations/applications but it is generally not as good a CC2652P based USB adapter but those are not compatible with Phoscon/deCONZ.

Personally, I try to foremost promote the ZHA integration because it is the built-in Zigbee integration and it is easier to get started, however, I also use Zigbee2MQTT for some odd devices since it was have more cutting-edge support for odder devices out-of-the-box without having to code quirks for ZHA.

But if you are a programmer yourself then you might just want to use the integration/application that is coded in the programming language that you prefer to code in. ZHA in written Python script and Zigbee2MQTT is JavaScript/TypeScript. Phoscon/deCONZ is proprietary and mostly closed source.

[Hedda]

By the way, be sure to also read this → Generic best practice tips on improving Zigbee network range and general stability · zigpy/zigpy Wiki · GitHub

Oh, IMHO, for about $20-30 might just buy a CC2652P adapter to test both ZHA and Zigbee2MQTT

https://community.home-assistant.io/t/iteads-sonoff-zigbee-3-0-usb-dongle-plus-model-zbdongle-p-based-on-texas-instruments-cc2652p-20dbm-radio-mcu-now-sold-for-19-99/340705

ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio MCU now sold for $19.99

UPDATED! The announced TI CC2652P based “Sonoff Zigbee 3.0 USB Dongle Plus” from ITead, later renamed to “ZBDongle-P”, has been released and looks to be great value for a premium hardware package sold for a low price. It is based on Texas Instruments CC2652P radio chip and this “ZBDongle-P” variant is to be sold side-by-side as an alternative to their new “ZBDongle-E” variant that is based on Silicon Labs EFR32MG21 that SoC chips both practically have the same specifications on paper but uses di…

and as you can later migate and re-use any CC2652P adapters as Zigbee Router (signal-repeater/range-extender) by reflashing its firmware you might as well also pre-order Home Assistant SkyConnect USB Stick as well for another $30-40 since it will also enable support for Thread/OpenThread (and Matter over Thread) in the future.

https://community.home-assistant.io/t/home-assistant-skyconnect-usb-stick-announced-will-be-compatible-with-both-zigbee-and-thread-including-matter-chip-over-thread/433594/

Home Assistant SkyConnect USB Stick announced - will be compatible with both Zigbee and Thread (including Matter/CHIP over Thread)

FYI, Nabu Casa’s Zack Barett has announced on Twitter that Home Assistant founders are working on an official Home Assistant SkyConnect USB Stick (ie. a physical radio adapter/dongle hardware). Nabu Casa electronics engineer developer (and Home Assistant developer) agners is designing the hardware for this USB RF-radio hardware for direct-attachment via USB will be based on a Silicon Labs EFR32MG21 SoC and that is an IEEE 802.15.4 multi-protocol 2.4GHz radio MCU that is capable of concurrently …

[Phil_123]

@Hedda, thanks for the tipps! So I got a ConBee 2 adapter and tried to pair the devices. I learned two things:

1. The Cosmo CRTDW is actually a rebranded (and 30€ more expensive) version of the Salus SQ610. I realized that because the Thermostat identified itself to home assistant as SQ610.
2. Unfortunately this device requires a custom hand-shake protocoll in order to bind, which is of course absolute crap. I will try to write Salus, but my hopes are low. I could buy a Salus Gatewaym as this was integrated into HA, but I do not want to. Other people tried to reverse engineer the handshake protocol, but apparently with no success. Even if I could sniff the connection request, I have little hope that I would be better suited at reverse engineering this protocol.

So success and no success? If you have a good recommendation or tipp, please do not hesitate to share .

[Hedda]

@Phil_123

I learned two things:

1. The Cosmo CRTDW is actually a rebranded (and 30€ more expensive) version of the Salus SQ610. I realized that because the Thermostat identified itself to home assistant as SQ610.
2. Unfortunately this device requires a custom hand-shake protocoll in order to bind, which is of course absolute crap. I will try to write Salus, but my hopes are low. I could buy a Salus Gatewaym as this was integrated into HA, but I do not want to. Other people tried to reverse engineer the handshake protocol , but apparently with no success. Even if I could sniff the connection request, I have little hope that I would be better suited at reverse engineering this protocol.

It will need a custom quirk for sure, so a new device support request to ZHA Device Handlers issues to open a new dialog for advice there with other community custom quirk developers → Issues · zigpy/zha-device-handlers · GitHub

Then if you are a programmer the other developers there should be able to point you in the right direction for writing a ”custom quirk” for ZHA Device Handlers, however recommend look at existing quirks for similar devices of the same Salus brand or other TVR producs
and read their readme file → GitHub - zigpy/zha-device-handlers: ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices.

Regardless be sure to upgrade firmware on your Zigbee Coordinator adapter and always use a long USB extension cable to try avoid interference.

[Phil_123]

@Hedda: thanks for the response. But I still need to know how this handshake protocol works right? Because if I dont, I cannot write a quirk, is that correct?

You said:

[…] look at existing quirks for similar devices of the same Salus brand […]

They only added the SP600 which is a smartplug. But as far as I can tell, there is no handshake involved in this code, or am I mistaken? Do you know of any code example in which someone tried to emulate such a handshake?

[Hedda]

FYI, there look to be a old closed request here but there are more active developers there today so can probably get more attention now if start a new brand request under issues instead for updated research and ideas → [Device Support Request] Salus SQ610 · Issue #571 · zigpy/zha-device-handlers · GitHub

[Hedda]

@Phil_123

But I still need to know how this handshake protocol works right? Because if I dont, I cannot write a quirk, is that correct?

@Phil_123

Do you know of any code example in which someone tried to emulate such a handshake?

You really (yes really) need to post a new request under issues there for such questions as tracking support requests for new devices and practically no developers post here in the forum, so all such quirk code dicussions are only handled on github → Issues · zigpy/zha-device-handlers · GitHub

Even exising developers can and do post issues there on github in order to start a quirk dialogs for new devices. That is the place to do so, not here in the forum.

Anyway, I would not expect to get deep coding answers from developers on what you can and can not do with quirks or how here in the forums.

[Phil_123]

You really (yes really)

really? Jokes aside, thanks for the tipps. I will do so!