search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.67k stars 1.64k forks source link

[New device support]: Philips Hue Secure Floodlight Camera EU (929003608801) #21650

Open JohnConnett opened 5 months ago

JohnConnett commented 5 months ago

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

const {} = require('zigbee-herdsman-converters/lib/modernExtend');
// Add the lines below
const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const ota = require('zigbee-herdsman-converters/lib/ota');
const tuya = require('zigbee-herdsman-converters/lib/tuya');
const {} = require('zigbee-herdsman-converters/lib/tuya');
const utils = require('zigbee-herdsman-converters/lib/utils');
const globalStore = require('zigbee-herdsman-converters/lib/store');
const e = exposes.presets;
const ea = exposes.access;

const definition = {
    zigbeeModel: ['unknown'],
    model: 'UNKNOWN', // Update this with the real model of the device (written on the device itself or product page)
    vendor: 'Signify Netherlands B.V.', // Update this with the real vendor of the device (written on the device itself or product page)
    description: 'Philips Hue Secure Floodlight Camera EU', // Description of the device, copy from vendor site. (only used for documentation and startup logging)
    extend: [],
    fromZigbee: [], // We will add this later
    toZigbee: [], // Should be empty, unless device can be controlled (e.g. lights, switches).
    exposes: [e.battery(), e.temperature(), e.humidity()], // Defines what this device exposes, used for e.g. Home Assistant discovery and in the frontend
};

module.exports = definition;
JohnConnett commented 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:

  1. Can the product be stimulated to invoke network steering only?
  2. Can the product be stimulated to invoke finding and binding only?
  3. Does the node support reception of the Mgmt_NWK_Update_req ZDO command?
  4. Is the logical device type specified as a ZigBee end device?
  5. Can the end device node join another network?
  6. Is the end device sleepy?
  7. Can the node join a centralized security network?
  8. Can the node join a distributed security network?
  9. Does the node contain the default global Trust Center link key?
  10. Does the node contain the distributed security global link key?
  11. Does the node contain an install code derived preconfigured link key?
  12. Does the node support install codes?
  13. Will the node be available via retail channels?
  14. Does the node not have a user configuration mechanism that allows switching between a mode in which only networks that require the use of install codes for joining are considered and a mode in which all networks are considered for joining?
  15. Can the node join all types of networks?
  16. Does the node support network steering for a node not on a network?
  17. Is the device implemented as having a simple device class (see [R4])?
  18. Does the device support finding and binding as either an initiator or a target?
  19. Does the device provide a mechanism to invoke finding and binding on the device itself?
  20. If network steering is attempted does the node follow the correct steering procedure dependent on whether the node is joined to a network or not?
  21. Does the node attempt finding and binding only if it is joined to a network?
  22. Does the node instigate finding and binding on one or more endpoints implemented on the node?
  23. Does the node attempt finding and binding as an initiator endpoint if the endpoint supports a type 1 client or type 2 server cluster?
  24. Can the node process the ZDO Active_EP_req command and respond with the ZDO Active_EP_rsp command?
  25. Can the node process the ZDO Node_Desc_req command and respond with the ZDO Node_Desc_rsp command?
  26. Can the node process the ZDO Simple_Desc_req command and respond with the ZDO Simple_Desc_rsp command?
  27. Can the node process the ZDO IEEE_Addr_req command and respond with the ZDO IEEE_Addr_rsp command?
  28. Can the node process the ZDO NWK_Addr_req command and respond with the ZDO NWK_Addr_rsp command?
  29. Can the node process the ZDO Match_Desc_req command and respond with the ZDO Match_Desc_rsp command?
  30. Can the node process the ZDO Mgmt_Bind_req command and respond with the ZDO Mgmt_Bind_rsp command?
  31. Can the node process the ZDO Mgmt_Lqi_req command and respond with the ZDO Mgmt_Lqi_rsp command?
  32. Can the node process the ZDO Bind_req command and respond with the ZDO Bind_rsp command?
  33. Can the node process the ZDO Unbind_req command and respond with the ZDO Unbind_rsp command?
  34. Can the node process the ZDO Mgmt_Leave_req command and respond with the ZDO Mgmt_Leave_rsp command?
  35. If the node supports finding and binding as an initiator, does it support the identify cluster as a client?
  36. If the node supports finding and binding as an initiator, can it process at least one identify cluster, identify query response command after broadcasting an identify cluster, identify query command?
  37. If the node supports finding and binding as an initiator, can it process more than one identify cluster, identify query response command after broadcasting an identify cluster, identify query command?
  38. If the node supports finding and binding as an initiator, does it implement a binding table whose number of entries is ≥ the sum of cluster instances supported on each device?
  39. If the node supports finding and binding as an initiator, regardless of the commissioning mechanism, is the binding table consistent such that its contents can be retrieved using the ZDO Mgmt_Bind_req command?
  40. Does the node have at least one attribute that is specified as mandatory and reportable?
  41. Does the node have a default reporting configuration for every attribute that is specified as mandatory and reportable?
  42. Does the node automatically send reports to a node that binds with a cluster containing an attribute that is specified as mandatory and reportable?
  43. If any default reporting configuration is overwritten, is the updated reporting configuration used instead?
  44. If the maximum reporting interval of an attribute is greater than 0x0000, is a report generated when the time that has elapse since the previous report of the same attribute is equal to the maximum reporting interval for that attribute?
  45. If the maximum reporting interval of an attribute is equal to 0x0000, is a report generated when the attribute value changes?
  46. Is the MAC data polling rate dynamic based on the operating state of the node?
  47. Does the node have at least a fast and a slow MAC data polling rate?
  48. Does the device poll more frequently than once per 7.5 seconds?
  49. While waiting for an active response message, does the node poll at its fast rate?
  50. Is the fast poll rate at least once every 3 seconds?
  51. While not actively waiting for messages, does the node poll at its slow rate?
  52. Does the node poll at its fast rate during commissioning?
  53. Does the node preserve the value of the bdbNodeIsOnANetwork attribute across resets?
  54. Does the node support the initialization procedure?
  55. Does the node restore its persistent ZigBee data?
  56. If the node is a ZigBee End Device and was previously on a network, does it attempt to rejoin the network?
  57. On successful rejoining, does the node broadcast a device_annce ZDO command?
  58. Does the implementation provide a mechanism to invoke network steering?
  59. Does the implementation provide a mechanism to invoke finding and binding?
  60. Is the network steering for a node not on a network procedure supported?
  61. Does the node attempt to discover networks over a set of channels?
  62. If suitable networks were found, does the node attempt to join one of them using MAC association?
  63. If the join was not successful and there are more suitable networks to join, does the node attempt to join another network?
  64. If the join was successful, does the node wait apsSecurityTimeOutPeriod milliseconds to receive the network key?
  65. If the network key is not received within apsSecurityTimeOutPeriod milliseconds, the network key is received but could not be decrypted or the authentication fails does the node reset its network parameters?
  66. Does the node broadcast a Device_annce ZDO command?
  67. If the TC link key exchange is not successful, does the node reset its network parameters and remove itself from the network?
  68. If the TC link key exchange is successful, does the node broadcast the Mgmt_Permit_Joining_req ZDO command?
  69. Is the finding & binding for an initiator endpoint procedure supported?
  70. Is the Identify cluster Identify Query command broadcast supported?
  71. Is the simple descriptor of each respondent obtained with the Simple_Desc_req ZDO command?
  72. Does the initiator create a binding table entry for each matching cluster to the respondent?
  73. On receipt of a leave NWK command frame with the request bit set to 1, does the end device node leave the network?
  74. On receipt of an Mgmt_Leave_req ZDO command frame, does the end device node leave the network?
  75. Does the node provide a local reset mechanism?
  76. On activation of the local reset mechanism, does the node reset itself?
  77. Does the node exchange its link key during network steering on a centralized security network?
  78. If the APS Request Key method is used or the alternative mechanism is not successful, does the node transmit the Node_Desc_req ZDO command to the Trust Center?
  79. If a Node_Desc_rsp ZDO command is not received within bdbcTCLinkKey-ExchangeTimeout seconds does the node retry up to the maximum attempts permitted?
  80. If a Node_Desc_rsp ZDO command is not received after the maximum number of attempts permitted, does it terminate the node link key exchange procedure?
  81. If a 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?
  82. If a 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?
  83. If a Transport Key APS command is not received within bdbcTCLinkKey-ExchangeTimeout seconds does the node retry up to the maximum attempts permitted?
  84. If a Transport Key APS command is not received after the maximum number of attempts permitted, does it terminate the node link key exchange procedure?
  85. If a Transport Key APS command frame is received from the Trust Center, containing a new link key, does the node update its Trust Center link key with the new key?
  86. Does the node verify the new key using the Verify Key APS command frame to the Trust Center?
  87. If a Confirm Key APS command is not received within bdbcTCLinkKey-ExchangeTimeout seconds does the node retry up to the maximum attempts permitted?
  88. If a Confirm Key APS command is not received after the maximum number of attempts permitted, does it terminate the node link key exchange procedure?

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?

JohnConnett commented 5 months ago

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.

JohnConnett commented 5 months ago

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?

JohnConnett commented 5 months ago

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.

JohnConnett commented 5 months ago

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).

JohnConnett commented 5 months ago

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 ...

JohnConnett commented 5 months ago

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!

JohnConnett commented 5 months ago

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})],
    },
JohnConnett commented 5 months ago

Submitted a pull request Picture for Hue Secure Floodlight Camera #2651.

JohnConnett commented 5 months ago

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?

Koenkk commented 5 months ago

@JohnConnett both are valid, I've updated the code in your pr and merged it, many thanks!

JohnConnett commented 5 months ago

@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 ...

JohnConnett commented 5 months ago

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.

JamieShatford commented 5 months ago

Great Job!

You're the only hope I have for these Hue Floodlight Cameras!

JohnConnett commented 5 months ago

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 ...

JamieShatford commented 5 months ago

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.

JohnConnett commented 5 months ago

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):

  1. colorCapabilities
  2. colorTempPhysicalMin
  3. colorTempPhysicalMax
  4. colorMode
  5. currentX
  6. currentY
  7. enhancedCurrentHue
  8. currentSaturation
  9. 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?

JohnConnett commented 4 months ago

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.

JohnConnett commented 4 months ago

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.

JohnConnett commented 4 months ago

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 ...

JamieShatford commented 4 months ago

Have you had anymore luck with this John?

JohnConnett commented 4 months ago

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!