-
Notifications
You must be signed in to change notification settings - Fork 675
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
[Device Support Request] Bosch Twinguard #2561
Comments
Is that "Bosch Twinguard" a Zigbee 3.0 device or? If so then you just have to type in "install code" in order to commission that specific Zigbee device, did you do that? ....Is it a Zigbee/CSA certified product or? https://csa-iot.org/csa-iot_products/ I can not find any Zigbee info about it. Wondering if Bosch has posted specifications for it and which Zigbee profile(s) it supports? Anyway, debug logs? https://www.home-assistant.io/integrations/zha#debug-logging You also need to provide the "Diagnostics" information (as well as the "Zigbee Device Signature" if possible but guess it is not): https://www.home-assistant.io/integrations/zha#reporting-issues Which Zigbee Coordinator adapter/dongle (Zigbee SoC brand and model) and exact firmware version have you tested with? Note that not all ZHA-compatible radio adapters/dongles support commissioning via “Install Code” or “QR Code” as of yet. See: https://www.home-assistant.io/integrations/zha#limitations "Support for commissioning Zigbee 3.0 devices via “Install Code” or “QR Code” via the ‘zha.permit’ service has so far only been implemented for ‘ezsp’ (Silicon Labs EmberZNet) or ‘znp’ (Texas Instruments) radio type in ZHA. Other radio types are missing support in their respective radio libraries for zigpy or manufacturer’s firmware commands/APIs." deCONZ serial protocol for ConBee/RaspBee Zigbee Coordinator adapters does not yet support joining/pairing via install code or qr code, and that is due to the manufacturer (dresden-elektronik) not fully documenting their serial protocol for it. See: and dresden-elektronik/deconz-serial-protocol#20 So if you want to use commissioning via “Install Code” today then you at least need a new Silicon Labs or Texas Instruments) radio. PS: This is the same for Zigbee2MQTT / zigbee-herdsman when it comes to and deCONZ serial protocol for ConBee/RaspBee. See: and |
Hmm, according to Bosch's Twinguard help it uses "ZigBee HA 1.2 protocol and proprietary, manufacturer-specific protocol extensions" which I would assume means that it uses its own non-standard custom manufacturer code with extensions for it? https://www.bosch-smarthome.com/uk/en/service/help/product-help/twinguard-help/ Check out this related Z2M discussion about Bosch Twinguard and Bosch Outdoor Siren using similar proprietary install code, what Bosch seem to call a “Device Local Key” in their Bosch Smart Home manual if using their own Zigbee gateway/bridge/hub: PS: Zigbee2MQTT has at least added Bosch Smart Home specific clusters and a zigbee-herdsman converter for Bosch Twinguard: Koenkk/zigbee-herdsman@b53b4d1 |
Hello, thanks for the fast research. I added logs and a photo to my first post. Seems as if the twinguards use a shorter installation code (16 bytes instead of 18). Looks like the Twingurad isn't going to ZHA? |
Reading the comments by Adminiuga and @atmurray in home-assistant/core#44805 it sounds as if the radio libraries could support shorter install codes if both ZHA and zigpy library (and its radio libraries) was patched to also accept 16-byte length of the install code when using the @atmurray even mentioned in that home-assistant/core#44805 that he could "prepare a pull request to patch ZHA's https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/core/helpers.py Suggest that you at the very least submit a new issue as a feature request about "support for shorter install codes" to the zigpy library/project since that is what Home Assistant's ZHA integration depends on: https://github.com/zigpy/zigpy/issues UPDATE: I submitted an issue for tracking this feature request: It sounds like ZHA Device Handlers (quirks) for such type of devices should be possible if the zigpy library/project already had support for shorter install codes in https://github.com/search?q=repo%3Azigpy%2Fzigpy%20zigpy%20convert_install_code&type=code At least now you have a clear use-case for such a request if now more than one device in Bosch Smart Home series requires this. That is, while the Zigbee 3.0 standard specifies that certified devices should only use 18-bytes install code, there clearly are some other commonly available devices that use Zigbee Home Automation (ZHA) profile with shorter non-standard install code length as a link key in a propriatory implementation (e.g. 16 bytes for Bosch Smart Home devices), as well as potentially 6-byte, 8-byte, 10-byte, 12-byte, 14-byte, 16-byte variants is possible in Zigbee Smart Energy (ZSE) devices, such as example Jetlun RD77715 -> https://fccid.io/X5QRD77715/User-Manual/Users-Manual-1592194 "While Zigbee smart energy networks allow the installation code to be comprised of either 6-, 8-, 12-, or 16-byte random, hexadecimal number with a 2-byte CRC appended to the end, Zigbee 3.0 (Z3) networks specifically require 16-byte hexadecimal installation codes, also accompanied by a 2-byte CRC" PS: Again for reference, please note that install codes are currently only supported in zigpy radio libraries for newer Zigbee Coordinator adapters with new radio SoC chips from Silicon Labs and Texas Instruments, e.i. using either an EFR32MGxx based Zigbee Coordinator adapter** like ex. EFR32MG12/EFR32MG21 or an CC2652/CC1352 based Zigbee Coordinator adapter, (so at this point you can definitely not use/test on other Zigbee Coordinator adapters like ConBee/RaspBee, XBee, and ZiGate). |
Can you post the full QR code? Unfortunately, the install code doesn't appear valid even when you remove the length restriction. |
Hello, QrCode: |
Is this the entire QR code, nothing is missing? Compared to the one in the Z2M issue, yours is shorter by two octets: # Z2M
RB01SG0D83101826480040000000000000000000003C84FFFEEDA00BDLKCE5D5C1E3D59D1440ABFE85251205C36ADE4
# Yours
RB01SG0D836591B3CC0010000000000000000000000D6F0017E0870CDLK999F98A7DFBCA6DD3955823AD9089631 |
Must be the whole thing, I copied it on my cell phone camera. |
Just to be 100% sure it's not an app problem, could you post a photo of the QR code as well? The first example I posted validates properly with existing but the second one from your QR code does not. There's no link key in it even if you try every combination, which is unusual. |
Maybe mine is missing the crc? key - a byte array representing DSLK with length 16 or IC with length 18 |
Interesting. Your device's model number is The "Device Local Key" (
The supposed key within the QR code (without CRC) is:
There's currently no way to directly provide link keys not derived from install codes but you can easily patch them into your respective radio library (e.g. hardcode the key to be |
Guessing that a developer would have to buy the older "Bosch Smart Home Controller" (BSHC-1) and use Zigbee sniffer with Wireshark to sniff and dump Zigbee traffic when joining/paring this device to the official Bosch Smart Home Controller"? https://www.bosch-smarthome.com/uk/en/service/help/product-help/smart-home-controller-help/ BSHC-1 is more commonly available and costs a lot more than their newer gateway/bridge/hub is on-sale at Amazon right now: https://www.amazon.com/Bosch-Smart-Home-Controller-Zentraleinheit/dp/B01N7AE32J https://www.amazon.de/Bosch-Smart-Home-Controller-Zentraleinheit/dp/B01N7AE32J By the way, the Bosch Twinguard also seems to be on-sale at Amazon's German site right now: https://www.amazon.de/-/en/detector-Twinguard-quality-measurement-connection/dp/B07V1P3W16/ Anyway, looks like their newer "Bosch Smart Home Controller II" (BSHC-2) should not be needed for the Bosch Twinguard device? https://www.bosch-smarthome.com/uk/en/products/devices/smart-home-controller According to their compatibility page it looks like both old BSHC-1 and new BSHC-2 should be compatible with Bosch Twinguard: https://www.bosch-smarthome.com/uk/en/service/help/compatibility-controller/ It is the newer "Bosch Smart Home Controller II" (BSHC-2) that is not compatible with some of their older devices unless adding their radio stick to it, though at least the Bosch Twinguard seems to be available with both the old and new Bosch controllers: https://www.bosch-smarthome.com/uk/en/products/control-elements-and-accessories/radio-stick/ |
I was able to recreate the crc. 999F-98A7-DFBC-A6DD-3955-823A-D908-9631-9F51 The installation code is accepted. The twinguard is also found, but cannot be added. I'll try again later and look at the logs. |
Is the installation code still the problem? Log
Device 0xe240 (00:0d:6f:00:17:e0:87:0c) joined the network Log
Logger: zigpy.application Received relays from an unknown device: 0xe240 |
@Smiley098 Yes, I think so. From your log, the device joins the network multiple times (indicative of it leaving and trying again) and is unresponsive. From the perspective of a Zigbee device, there are only link keys. They don't know or care about install codes. For that reason, manually appending a CRC to the
To try these out, you will need to try both keys directly by patching the radio library as I mentioned above. Using them as install codes probably won't work. |
FYI, screenshot from safakaltun of his Bosch Twingard also has device model number datenzar also posted to Koenkk/zigbee2mqtt#13520 saying that he figured out how to decode the link keys from sniffed packages following stm32mcu docs; "The derivation is actually just the MMO (Matyas-Meyer-Oseas) hash of the install code + crc." (but that is way over my head) Originally posted by @datenzar in Koenkk/zigbee2mqtt#13520 (comment)
So, have Zigbee2MQTT been able to fully work around these Bosch quirk(s) in zigbee-herdsman and zigbee-herdsman-converters? Koenkk/zigbee-herdsman-converters#5176 Btw, are these same quirk(s) in more Bosch Smart Home series products than the Bosch Twinguard and the Bosch Outdoor Siren? |
I'm too stupid to find the file. :( I'll wait and see if someone else can do it. I was able to add the Bosch adapter plugs using the installation code. |
Not sure if related this issue(?) but FYI; noticed @promasu has submitted PR to "Add support for Bosch QR-codes for zha.permit" home-assistant/home-assistant.io#29459
Note that since home-assistant/core#102427 was just merged it will not be available until Home Assistant core 2023.11 release. |
@Smiley098 Have you been able to add the Twinguard through ZHA in the meantime? I have exactly the same problem as you describe here.. |
@blatthew |
Can anyone provide a step by step documentation how to zniff bosch' smart home controller zigbee traffic? I've got an ember stick and am able to capture the encrypted traffic of the controller and a few brand new gen II smart home bosch devices (I've just bought). But I've no cue how to retrieve the network key from the captured traffic. |
I also just bought the Twinguards and realized they use a different scheme to the ordinary Bosch smoke detector 2 (missing the installation code)... The Smoke detector 2 connects fine by adding the Source IEE and installation code prior connecting to HA which the Twinguard is missing. I do have HA on Debian with a Skyconnect stick on a Debian VM. Any way I could help? QR code would be the following: RB01SG0D836591B3CC0010000000000000000000000D6F0019105047DLKE4F7A8C6A8C54F2281640ABC518B8A1B where 000D6F0019105047 is the Source IEEE. The local key is mentioned on the device but not in the QR code (so I assume its not needed (?)). |
Can you elaborate what these changes were and how you implemented it? Or did you alter the Sourcecode on ZHA? |
See home-assistant/core#107460 for further details |
Nice! Is Bosch Twinguard their only device that needs such a unique solution or could it also be applies to other Bosch devices? https://github.com/zigpy/zha-device-handlers/issues?q=is%3Aissue+Bosch |
So far yes it seems that it is their only devices. For Bosch Outdoor Siren I could not verify yet, as I do not have it physically to test. If one could count the characters after Zigpy internal does not directly passes along the installation code to the coordinator, but computes the AES MMO hash from the 18 bytes installation code + crc. |
does anyone get this running with Skyconnect? |
Okay, figured it out by myself
Added that key to wiresharks zigbee key list too, now I can see all traffic decrypted. |
With the update of today 2024.02 I could use the QR-Code. |
What kind of coordinator do you use? It is known to work with Texas Instrument based adapters (e.g. CC2652), but not with Silicon Labs (e.g. Skyconnect, HA yellow - EFR32 based) |
Pairing itself works (manual cluster querying works), but it requires further quirks (manual heartbeat, pairing complete, periodic reporting) I’ll try to push my changes soon to zha-quirks |
I use Skyconnect and ZHA. |
Thank you for your work! |
Same for me |
Hey everybody, Thanks for helping |
i just wonder if this a firmware issue or a quirk issue |
@idstein have you a custom quirk to use? Or do you think it can be enabled for ZHA? |
Hey @firstusing, I tried the Twinguard with the Zigbee2MQTT Integration an this works fine. So if you would like to use it you could also try this Integration. But therefore you have to switch all your Devices to zigbee2mqtt. This could also be a lot of work. |
I fixed the readings for the sensors, but struggling to get a continuous reporting. It looks like the values are not continuously send. Carbon Monoxide is actually not what the BME sensor provides. There is only a Indexed Air Quality available to indicate roughly VOC. |
The Screenshot is what the zigbee2mqtt Integration provides. https://www.zigbee2mqtt.io/devices/8750001213.html I also thought that I red, that the twinguard "only" measures voc instead of co2. But at the end of the day it dose not matter what the Integration shows as long as you know what it means. Also the siren can be switched in home assistant |
for me z2m with a skyconnect is also not working |
I have to say i do not see how it works, i changed from ZHA to Z2M completly, the paring does work great but after that.... no measurments at all. |
It depends on the z2m version. There are some issues with the new (1.36.1-1) version. You have to go back to the 1.36.0-1 than it should work. |
hi @idstein and all others here
what i understood in this thread is that with @idstein 's merged pull request binding should work via the QR code what i did:
then twinguard gets conected to my zigbee network but...
id there somewhere a step by step guide how to add the twinguard via ZHA to homeassistant? thank you for your input! UPDATE:
|
Same for me 😕 |
@idstein @KorbinianPei @Mar1usW3 @firstusing thank you so much! |
i know, nobody gets paid here and we all have to respond in our free time but still i'm a little bit sad to get no response, i'll send it back then and use another solution. |
Hello, |
I've got the However, I can force the values to update if I go into manage Zigbee device and manually retrieve the corresponding clusters. (However "carbon monoxide" -- which should really be VOC, I assume -- stays at 0 even after several hours.) I also tried to give it an attribute reporting interval via the ZHA Toolkit, which the device appears to accept, but it doesn't appear to change the behavior. It also won't report back the values I tried to set if I try to read out the reporting status. Just putting it out there, in case this clue might help with coming up with a fix! |
So I dove in and took a stab at an initial ZHA quirk myself, see the above PR. It's inspired by the Zigbee2MQTT implementation. If you want to test it yourself, you can drop twinguard.py from my PR into your custom quirks directory. It enables updating of temperature, humidity, illuminance, and raw VOC values. Smoke detection and alarm functions are not yet implemented. (I won't have time to work on that soon – if anybody else wants to have a crack, please feel free! They're implemented in the Z2M code, so it should be 'easy' to convert it.) In my experience, the measurement values begin reporting some minutes after pairing. I also needed to restart HA to see the new sensors. Note that the default Carbon Monoxide and Pressure clusters also show up but won't update automatically. I'm still not clear if there's even a Carbon Monoxide sensor or derived calculation in the device... I believe that what Z2M calls pressure from the 0xE002 data cluster is actually something else. For me, it usually sits stable at its max value of 1000, but occasionally dips to the 900s or 800s for a few minutes. It doesn't seem directly connected to VOC or anything else that's obvious. My PR doesn't at all address any pairing issues. In my case, I have a Conbee II stick, but the Twinguard never pairs directly with it, instead going through my Zigbee light switches (after doing the ZHA permit procedure with the QR code, as described above. Somehow this usually results in losing pairing with one or more of my other light switches, so I often need to repair those after getting the Twinguard paired. Home Assistant then reports successful pairing for me, while the Twinguard keeps blinking and eventually glows red (indicating that pairing failed on its side). But after holding down the button to get it back in pairing mode, it then quickly finds the network again and glows green. I believe the measurements might not get updated if you don't get the Twinguard to glow green... Hope this helps out some people here! |
Problem description
Hello,
Unfortunately, the message Installation code too short appears when I want to add the Twinguard (Zha-permit).
The twinguard cannot be added without a code.
home-assistant/core#44805
https://www.zigbee2mqtt.io/devices/8750001213.html
Solution description
Allow all installation code lengths?
Screenshots/Video
Screenshots/Video
Device signature
Device signature
[Paste the device signature here]
Diagnostic information
Diagnostic information
[Paste the diagnostic information here]
Logs
Logs
Custom quirk
Custom quirk
Additional information
SkyConnect Multi-PAN
Silicon Labs Multiprotocol
Current version: 2.3.2
The text was updated successfully, but these errors were encountered: