Open JohnConnett opened 5 months ago
Zigbee Certification: Hue Secure Camera 0124.
In the Compliance Document rev01-hwMP 1.0-sw2.75.3/16-02800-011-PRO-BDB-v3.0.1-XML-PICS-CMB001.xml
the following are true
:
Mgmt_NWK_Update_req ZDO
command?ZDO Active_EP_req
command and respond with the ZDO Active_EP_rsp
command?ZDO Node_Desc_req
command and respond with the ZDO Node_Desc_rsp
command?ZDO Simple_Desc_req
command and respond with the ZDO Simple_Desc_rsp
command?ZDO IEEE_Addr_req
command and respond with the ZDO IEEE_Addr_rsp
command?ZDO NWK_Addr_req
command and respond with the ZDO NWK_Addr_rsp
command?ZDO Match_Desc_req
command and respond with the ZDO Match_Desc_rsp
command?ZDO Mgmt_Bind_req
command and respond with the ZDO Mgmt_Bind_rsp
command?ZDO Mgmt_Lqi_req
command and respond with the ZDO Mgmt_Lqi_rsp
command?ZDO Bind_req
command and respond with the ZDO Bind_rsp
command?ZDO Unbind_req
command and respond with the ZDO Unbind_rsp
command?ZDO Mgmt_Leave_req
command and respond with the ZDO Mgmt_Leave_rsp
command?ZDO Mgmt_Bind_req
command?bdbNodeIsOnANetwork
attribute across resets?device_annce
ZDO command?apsSecurityTimeOutPeriod
milliseconds to receive the network key?apsSecurityTimeOutPeriod
milliseconds, the network key is received but could not be decrypted or the authentication fails does the node reset its network parameters?Device_annce
ZDO command?Mgmt_Permit_Joining_req
ZDO command?Simple_Desc_req
ZDO command?Mgmt_Leave_req
ZDO command frame, does the end device node leave the network?Node_Desc_req
ZDO command to the Trust Center?Node_Desc_rsp
ZDO command is not received within bdbcTCLinkKey-ExchangeTimeout
seconds does the node retry up to the maximum attempts permitted?Node_Desc_rsp
ZDO command is not received after the maximum number of attempts permitted, does it terminate the node link key exchange procedure?Node_Desc_rsp
ZDO command is received and the server mask of the node descriptor indicates a core stack of r20 or earlier, does the node terminate the node link key exchange procedure?Node_Desc_rsp
ZDO command is received and the server mask of the node descriptor indicates a core stack of r21 or later, does the node request a new link key using the Request Key APS command frame to the Trust Center, encrypted with its initial link key?bdbcTCLinkKey-ExchangeTimeout
seconds does the node retry up to the maximum attempts permitted?Some of these (5, 7, 8, 12, 15) suggest that there may be ways for this device to join an existing network. The Hue Secure wired camera Ownership card has a Setup code (six hex digits); a Device ID (12 hex digits) and a QR Code which represents 127 characters starting with "MT:" with the rest being composed of ".", "-", "[0-9]", "[A-Z]".
Maybe there is some way to obtain an install code and use that to join an existing network?
The shape of the decoded QR Code is: MT:AB012CD.34EFGH5IJ6K7-L8M9NO.P0QRS12TUVW34X5Y6Z7-A8-BC9012D3456EF78-GH9012I345JK67LMN8OPQR9S-012T-UV3WXYZ4A5BC6DEF.7GH-I8J901
.
Note that these are not the actual values for my camera! I have replaced the upper-case letters with a repeating sequence of A-Z and decimal digits with a repeating sequence of 0-9.
My initial guess was that it is Base36 encoded. However, none of the component parts decode to 144-bits of an install code and CRC.
If anything about the shape of the decoded QR Code looks familiar or you have other suggestions for extracting the install code please let me know.
Found another QR Code on the back of the common base for the floodlight and camera. This does decode to something that contains a 144-bit value in hex.
Anybody know of a handy tool that will verify the CRC of an install code?
Here's the shape of the second QR Code: HUE:Z:0123456789ABCDEF0123456789ABCDEF0123 M:0123456789ABCDEF D:L3B A:1184
. Again, these are not the actual values! My guess is that the hex after 'Z:' is the install code and the hex after 'M:' is the IEEE address.
Here's the shape of the second QR Code:
HUE:Z:0123456789ABCDEF0123456789ABCDEF0123 M:0123456789ABCDEF D:L3B A:1184
. Again, these are not the actual values! My guess is that the hex after 'Z:' is the install code and the hex after 'M:' is the IEEE address.
Unfortunately, it looks like the IEEE Address is from the floodlight (which can be joined to an existing network in the same ways as for other Hue lights).
It appears that the 12 hex digit Device ID on the Hue Secure wired camera Ownership card is the MAC address which can be converted to a Extended Unique Identifier (EUI) as described in Understanding IPv6 EUI-64 Bit Address. For example:
C42996123456
becomes C42996FFFE123456
. Note that C42996 is the vendor id for Signify B.V..
Now I just need a way to obtain the install code ...
Sent the following DM to Philips Hue on Facebook:
I have a Philips Hue Secure Floodlight Camera EU which I would like to integrate with the Home Assistant home automation software.
As it is a Zigbee Certified Product it should be possible to commission it into an existing Zigbee network. A key strength of Zigbee is interoperability. In the Zigbee Certification for "Hue Secure Camera 0124" both of these items are marked as true: "Does the node support install codes?"; "Can the node join all types of networks?".
The problem is how to determine the install code (typically a 144-bit value) and IEEE Address (a EUI-64 Extended Unique Identifier). For some other Zigbee devices these are encoded into a QR Code attached to it. I have the Hue Secure wired camera Ownership card which holds a six hex digit "Setup code"; a 12 hex digit "Device ID" and a QR Code. I can read the QR Code as a 127 character string starting with "MT:". However, I have been unable to extract anything from that character string that resembles an install code or IEEE Address.
Details of my efforts so far can be found here: https://github.com/Koenkk/zigbee2mqtt/issues/21650
Being able to operate with Home Assistant and other home automation software could increase the attractiveness of the Hue Secure camera range by taking advantage of the interoperability inherent in Zigbee without compromising the security provided by the end-to-end encryption of the WiFi + Internet connection.
I appreciate that this a rather technical question. So far, I have not found a source to provide an answer. Can you help?
Here is the reply I received:
Hi John, Thanks for reaching out to us. Unfortunately Hue Camera's are not available to use with Friends of Hue or any other apps like Home Assistant this moment in time. We don't have any information to share about this (yet) if this will be implemented in the future or not. We recommend keeping an eye out on our socials / webstore blog to stay up to date with the most recent updates.
To my mind, having a Zigbee Certified Product with certification documentation that states that the node can join all types of networks and the node supports install codes makes a nonsense of Zigbee interoperability claims unless a mechanism is provided to obtain an install code!
Edited the Database entry for the floodlight part into the initial comment. Currently reported as:
warn 2024-03-24 15:18:55: Device '0x001788010e115407' with Zigbee model '442296118491' and manufacturer name 'Signify Netherlands B.V.' is NOT supported, please follow https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html
Suspect adding this to zigbee-herdsman-converters/src/devices/philips.ts
would fix it:
{
zigbeeModel: ['442296118491'],
model: '442296118491',
vendor: 'Philips',
description: 'Hue Secure Camera Floodlight',
extend: [philipsLight({colorTemp: {range: [153, 500]}, color: true})],
},
Submitted a pull request Picture for Hue Secure Floodlight Camera #2651.
Submitted a pull request Support for floodlight part of Hue Secure Floodlight Camera #7263.
First attempt failed with lint problems which I corrected. However, it is still failing.
I based it on the generated_external_definition
output with the description modified to "Hue Secure Camera Floodlight". The generated definition has color: {modes: [xy, hs], enhancedHue: true}
while other examples have just color: true
. I could just use color: true
but that would be guesswork rather than a decision based on knowledge!
Can anyone explain why there is a difference between the generated definition and the code? My external converter, /config/zigbee2mqtt/442296118491.js
:
const {philipsLight} = require('zigbee-herdsman-converters/lib/philips');
const definition = {
zigbeeModel: ['442296118491'],
model: '442296118491',
vendor: 'Signify Netherlands B.V.',
description: 'Hue Secure Camera Floodlight',
extend: [philipsLight({"colorTemp":{"range":[153,500]},"color":{"modes":["xy","hs"],"enhancedHue":true}})],
meta: {},
};
module.exports = definition;
appears to be working. Is it a JavaScript v. TypeScript issue?
@JohnConnett both are valid, I've updated the code in your pr and merged it, many thanks!
@JohnConnett both are valid, I've updated the code in your pr and merged it, many thanks!
Many thanks @Koenkk. Now I need to get the camera part to work ...
Thanks to excellent support from the Connectivity Standards Alliance I have managed to decode the QR Code on the Hue Secure wired camera Ownership card!
I submitted my question via the We’re Here to Help form, selecting Certification in the I want to know about... field.
The clue was the 'MT:' prefix of the 127 character string decoded from the QR Code. It is used for the newer Matter standard in the onboarding QR codes. I was informed that Matter onboarding payloads are encoded as Base38! The full details of the encoding is available in Chapter 5.1 of the Matter Specification.
I further decoded the 127 character string to a 74 byte array without any errors being detected.
This was decoded yet again manually to extract this fixed part:
Version 3 000 0x00
Vendor ID 16 0001 0000 0000 1011 0x100b
Product ID 16 0000 0000 0000 1100 0x000c
Custom Flow 2 10 0x2 // Custom commissioning flow
Discovery 8 0000 0100 0x0004 // On IP network
Capabilities
Bitmask
Discriminator 12 ???? ???? ???? 0x???
Passcode 27 ??? ???? ???? ???? ???? ???? ???? 0x???????
Padding 4 0000 0x00
I have used '?' to obscure the secret items.
The Tag-length-value (TLV) encoded variable part is:
11: 15 // Control byte for structure with anonymous tag
12: 30 // Control byte for octet string with 1-byte length and a context-specific tag
13: 80 // Context-specific tag
14: 12 // Length (18)
15: ?? // Install Code[0]
16: ?? // Install Code[1]
17: ?? // Install Code[2]
18: ?? // Install Code[3]
19: ?? // Install Code[4]
20: ?? // Install Code[5]
21: ?? // Install Code[6]
22: ?? // Install Code[7]
23: ?? // Install Code[8]
24: ?? // Install Code[9]
25: ?? // Install Code[10]
26: ?? // Install Code[11]
27: ?? // Install Code[12]
28: ?? // Install Code[13]
29: ?? // Install Code[14]
30: ?? // Install Code[15]
31: ?? // Install Code[16]
32: ?? // Install Code[17]
33: 30 // Control byte for octet string with 1-byte length and a context-specific tag
34: 81 // Context-specific tag
35: 06 // Length (6)
36: c4 // Device ID[0]
37: 29 // Device ID[1]
38: 96 // Device ID[2]
39: ?? // Device ID[3]
40: ?? // Device ID[4]
41: ?? // Device ID[5]
42: 30 // Control byte for octet string with 1-byte length and a context-specific tag
43: 82 // Context-specific tag
44: 08 // Length (8)
45: c4 // EUI-64 [0]
46: 29 // EUI-64 [1]
47: 96 // EUI-64 [2]
48: ff // EUI-64 [3]
49: fe // EUI-64 [4]
50: ?? // EUI-64 [5]
51: ?? // EUI-64 [6]
52: ?? // EUI-64 [7]
53: 2c // Control byte UTF-8 string with 1-byte length and a context-specific tag
54: 86 // Context-specific tag
55: 06 // Length
56: 43 // 'C' Model_id[0]
57: 4d // 'M' Model_id[1]
58: 57 // 'W' Model_id[2]
59: 30 // '0' Model_id[3]
60: 30 // '0' Model_id[4]
61: 32 // '2' Model_id[5]
62: 30 // Control byte for octet string with 1-byte length and a context-specific tag
63: 88 // Context-specific tag
64: 08 // Length (8)
65: ?? // Unknown[0]
66: ?? // Unknown[1]
67: ?? // Unknown[2]
68: ?? // Unknown[3]
69: ?? // Unknown[4]
70: ?? // Unknown[5]
71: ?? // Unknown[6]
72: ?? // Unknown[7]
73: 18 // End of container
Again, I have used '?' to obscure the secret (and unknown) parts. Apart from the last 64-bit item they all look plausible. The 144-bit item I have labelled as Install Code passed the CRC check. The Install Code and EUI-64 should be sufficient information for joining a Zigbee network always assuming that the camera can be placed in the right state for joining ...
The existing QR Code handling in Zigbee2MQTT uses regular expressions for the decoding. I doubt if that approach would be adequate for this format of QR Code!
Another part of the puzzle solved with the excellent support from the Connectivity Standards Alliance.
Great Job!
You're the only hope I have for these Hue Floodlight Cameras!
You're the only hope I have for these Hue Floodlight Cameras!
I suspect that any solution would probably work for all Hue Secure wired cameras and, maybe, the wireless ones, too.
The Custom Commissioning Flow - interaction with a vendor-specified means is needed before commissioning could prove to be another challenge! The current route probably involves the Hue App receiving a Bluetooth LE (BLE) broadcast from the camera then probably talking BLE or Wi-Fi to the camera to trigger the Zigbee commissioning to the Hue Bridge. Not easy to sniff, especially if much of it is encrypted.
Other avenues may open up when the planned support for other platforms arrives.
My approach is strictly software. More might be learnt from exploring the hardware but I don't want to risk wrecking my camera!
It would be good to find someone with a rooted Hue Bridge to see if more can be determined from that end of the official Zigbee connection. That Might try it myself if all else fails ...
I'll try to find someone with a Routed Hue Bridge, I'm in quite a few Facebook groups with Hue Guru's, I'll direct them to this post.
On another note, I have a Aqara G4 and I did think to myself, is there a way to swap the hardware in the camera to have it pose as a Aqara device as they have identical features apart from the light of course.
It's a long shot and defiantly won't work but if they're both using ribbon cables I bet a hardware specialist could make it work.
I'm just being hopeful and talking of an idea, but I'm well aware it's probably impossible.
I have just compared the /config/zigbee2mqtt/database.db
entries for the floodlight part ("modelId": "442296118491"
) with a Hue white and color ambiance E26/E27 1600lm bulb ("modelId": "LCA008"
). There are some differences.
floodlight "inClusterList": [0,3,4,5,6,8,768,4096,64513,64515,64516]
bulb "inClusterList": [0,3,4,5,6,8,768,4096,64513,64514]
There is code to handle cluster 64515 (0xFC03, manuSpecificPhilips2) in zigbee-herdsman/src/zcl/definition/cluster.ts
but nothing I could see for manufacturer-specific clusters 64513, 64514 and 64516.
In the genBasic cluster, floodlight has "zclVersion": 8
and bulb has "zclVersion": 2
.
In the lightingColorCtrl cluster, floodlight has three attributes (1-3) and bulb has nine attributes (1-9):
colorCapabilities
colorTempPhysicalMin
colorTempPhysicalMax
colorMode
currentX
currentY
enhancedCurrentHue
currentSaturation
colorTemperature
The genLevelCtrl cluster was missing for floodlight and present with a single currentLevel
attribute for bulb.
I don't have sufficient depth of knowledge to understand if these differences are significant.
The missing genLevelCtrl cluster is particularly odd as 8 (0x0008, genLevelCtrl) is in the inClusterList
for floodlight. It appears to be a derived cluster as described in 3.19 Level Control for Lighting in the Zigbee Cluster Library Specification which has a mandatory CurrentLevel
attribute.
Maybe @Koenkk might have some comments?
Some more investigation using the QR Code on the Hue Secure wired camera Ownership card.
First the Google Home Android App installed from the Google Play Store onto GrapheneOS:
Google Home Android App
Devices -> + Add -> Matter-enabled device
Scan QR Code
No Wi-Fi connection
Although it reports No Wi-Fi connection my mobile has a good direct connection to my Wi-Fi which I confirmed by running the ConnectBot App to connect to a Linux system. The VPN was disabled.
Next the CHIPTool Android App. I did try to build it myself but there is a steep learning curve for Android Studio and the tools needed to build it. Found a binary chip-tool-android_aarch64.apk and installed onto GrapheneOS. Note that it dates from December 2022 so it may be out-of-date. Might make another effort to build an up-to-date version of the app.
CHIPTool Android App
SCAN QR CODE
Same data as Linux CHIPTool
PROVISION CHIP DEVICE WITH WI-FI
Scan QR Code
Enter Wi-Fi credentials
SAVE NETWORK
Scanning for BLE device <12-bit discriminator in decimal?>
PROVISION CHIP DEVICE WITH THREAD
Enter credentials of the Thread network [...]
SAVE NETWORK
Scanning for BLE device <12-bit discriminator in decimal?>
Device not found
PROVISION CHIP DEVICE WITH CUSTOM FLOW
MT:???????????????????
Scan QR Code
Same data as Linux CHIPTool
The 'MT:' code displayed during the Custom Flow case decodes to VendorID: 9050 (0x235A); ProductID: 65279 (0xFEFF).
Both apps successfully scan the QR Code but do not appear to do much more. My Hue Bridge was switched off but I also have a Google Nest Hub Gen. 2 which is a Matter device and supports Bluetooth, Wi-Fi and Thread.
There might be more to be learnt from investigating the source of CHIPTool, particularly what happens during provisioning. Curious to know how the <12-bit discriminator in decimal?> is used with Bluetooth.
Will try a factory reset of the camera part which should trigger Bluetooth advertisements to see if that makes a difference.
Here is the Bluetooth LE packet that is emitted after a factory reset of the camera part and a power cycle:
Bluetooth Low Energy Link Layer
Access Address: 0x8e89bed6
Packet Header: 0x1900 (PDU Type: ADV_IND, ChSel: #1, TxAdd: Public)
.... 0000 = PDU Type: 0x0 ADV_IND
...0 .... = Reserved: 0
..0. .... = Channel Selection Algorithm: #1
.0.. .... = Tx Address: Public
0... .... = Reserved: 0
Length: 25
Advertising Address: Signify_01:23:45 (c4:29:96:01:23:45)
Advertising Data
Flags
Length: 2
Type: Flags (0x01)
000. .... = Reserved: 0
...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
.... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
.... .1.. = BR/EDR Not Supported: true (0x1)
.... ..1. = LE General Discoverable Mode: true (0x1)
.... ...0 = LE Limited Discoverable Mode: false (0x0)
16-bit Service Class UUIDs (incomplete)
Length: 3
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Signify Netherlands B.V. (formerly Philips Lighting B.V.) (0xfe0f)
Service Data: cc12ffff000e1400
CRC: 0x012345
I have changed the last three bytes of the Advertising Address and the CRC, although the really secret stuff is probably the out-of-band data from the Hue Secure wired camera Ownership card. Note that the Hue app wasn't running on my mobile. Note that the packet isn't in Zigbee Direct format.
Used the excellent nRF Sniffer for Bluetooth LE using 6.3 Sniffing a connection involving a single Peripheral with the camera's public address. Powered on the camera and started the Hue app. Followed the on screen instructions until Camera connected! was displayed. Ended the capture there and didn't proceed to Set up Wi-Fi.
In among the thousands of packets captured were four with Protocol ZBD. Looks like it might be using Zigbee Direct under the hood! Suspect more research will be required to understand what can be done with that information.
Wonder if it uses matter BLE Wi-Fi commissioning? That investigation is for another day ...
Have you had anymore luck with this John?
Have you had anymore luck with this John?
Unfortunately, I have been occupied with other things. I have started reading about BLE and ZBOSS with the aim of trying to understand the BLE interaction between the Hue App and the camera then, maybe, try to emulate that part of the Hue App using my nRF5340 DK. I also have a nRF7002 EK shield so the same hardware is capable of BLE, Wi-Fi 6 and Zigbee.
Asked about Zigbee Direct support?. Not currently supported by the latest nRF Connect SDK so some additional code would be required to process the Zigbee Direct packets.
Another possibility is using APKLab to investigate the Hue App.
Hope to find time for more work on this. It's an interesting challenge!
Link
https://www.philips-hue.com/en-gb/p/hue-philips-hue-secure-flood-light-camera-eu/8720169177703
Database entry
Floodlight Part:
{"id":16,"type":"Router","ieeeAddr":"0x001788010e115407","nwkAddr":48753,"manufId":4107,"manufName":"Signify Netherlands B.V.","powerSource":"Mains (single phase)","modelId":"442296118491","epList":[11,242],"endpoints":{"11":{"profId":260,"epId":11,"devId":269,"inClusterList":[0,3,4,5,6,8,4096,64515,768,64513,64516],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"442296118491","manufacturerName":"Signify Netherlands B.V.","powerSource":1,"zclVersion":8,"appVersion":2,"stackVersion":1,"hwVersion":0,"dateCode":"20230403","swBuildId":"1.104.2"}},"lightingColorCtrl":{"attributes":{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":500}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":2,"stackVersion":1,"hwVersion":0,"dateCode":"20230403","swBuildId":"1.104.2","zclVersion":8,"interviewCompleted":true,"meta":{"configured":1324213189},"lastSeen":1711293848840}
Comments
This is a slightly unusual device. It is essentially two devices: a Zigbee Colour Floodlight and a Secure Camera sharing a common base and power supply.
Although the packaging describes it as a Zigbee Certified Product the camera part is unable to pair with Zigbee2MQTT. Nor does it support pairing using Zigbee Direct using Bluetooth LE (BLE). Although Zigbee2MQTT can pair with any Zigbee device this appears to be an exception ...
It can be commissioned into a Zigbee network with a Philips Hue Bridge as coordinator using the proprietary Philips Hue App using WiFi and BLE. The BLE advertisements emitted during setup do not conform to the BLE Connectable Advertisement example in Appendix A of Zigbee Direct Specification, Version 1.0. In particular, instead of the 16-bit UUID of the Zigbee Direct Commissioning Service (0xFFF7) it has the 16-bit UUID of Signify Netherlands B.V. (formerly Philips Lighting B.V.) (0xFE0F).
It may not be feasible to support this device with Zigbee2MQTT.
I have set up a GitHub repository Hue-Secure-Camera to collate information about this device.
External definition