Multi_sensor Zigbee example - wrong device type using official Nordic nrf52840DK

[inixie]

Capturemulti-sensorChannel14.pcapng

Hi,

I am trying to test multi_sensor example from Zigbee and Thread SDK 4.2 using official Nordic nrf52840DK with few Zigbee hubs.
Example is located in \examples\zigbee\experimental\multi_sensor\pca10056\blank\ses\
Only adjustments made are setting/confirming:
#define IEEE_CHANNEL_MASK                  (ZB_TRANSCEIVER_ALL_CHANNELS_MASK)
zb_err_code = zboss_start();

Unfortunately Nordic nrf52840DK loaded with multi_sensor firmware is showing as "Thing" in Smartthings Zigbee hub, and not showing at all in standard Zigbee hub in Tuya.
Till now I was able only to confirm that only "Light bulb" (ble_zigbee_dynamic_door_lock_nus) and "Door lock" (ble_zigbee_dynamic_door_lock_nus) examples do work both in Tuya and Smartthings.

Included is wireshark sniffer log and screenshot showing device type "Thing" in Smartthings hub.
Could anyone point me in right direction?

Reason for asking about "multi_sensor" was attempt to develop simple contact sensor that would show correctly in at least some Zigbee hubs.
I got same result, i.e. having simple contact sensor showing only as "Thing" in Smartthings Zigbee hub, and not showing at all in standard Zigbee hub in Tuya.


Thanks in advance

[Elfving]

Hello,

I will have to get back to you on this next week.

Regards,

Elfving

[Elfving]

Hello again,

Unfortunately Nordic nrf52840DK loaded with multi_sensor firmware is showing as "Thing" in Smartthings Zigbee hub,

You can change what sort of Zigbee thing this is in the app, for more info see here.

not showing at all in standard Zigbee hub in Tuya

That is odd. Could you provide a sniffer log of it attempting to connect to the Tuya? You've provided a sniffer log, but I'm not sure which of the two issues it is showing.

Regards,

Elfving

[inixie]

Thanks Elfving,

In initial attachment was sniffer log for Smartthings on channel 14, and here is sniffer log for Tuya on channel 15.

As per advice for adjusting Smartthings sensor type at Samsung website, I did attempt that, with mixed results (screenshots attached showing intermittent successful change). Basically sometime it works, but sensor did appear differently after repeated adjustments (sensor either shows just "Connected" or do show values like Temp etc). This behavior seems to partially depend on device initially chosen to do the scan (auto-scan doesn't seems to work). Initially I was able to change "Thing" (first choice of all devices in the list, maybe due to passing wrong ID to Smartthins) type to Zigbee Motion/Temp/Humidity Sensor. Unfortunately I wasn't able to replicate it consistently.

Capturemulti-sensorChannel15Tuya.pcapng

[inixie]

Hi Elfving,

Would be possible to get some follow-up, or at least advice about possible developer/company proficient with nrf52xx multi-sensors Zigbee implementation that I could contract regarding this?

Workaround suggested re adjusting detected sensor type at Smartthings web account, is really not something that I can pass to future customers.
None of the nrf52 related sensor code (mostly from github), other that light bulb/lock related, doesn't seems able to seamlessly join Smarthings or join at least standard Zigbee hub in Tuya.

In the meantime I did order few Zigbee sensors made with different manufacturer's SoC other than Nordic nrf52xx SoC; those sensors are joining okay both Smartthings and standard Zigbee hubs under Tuya. In addition I did check one SoC manufacturer's zigbee sensor IAR source code.
Their official code from github and its Tuya implementation, that apparently is working, seems to not have/use basic attribute list nor identify attribute list:

Contact sensor IAR code - non-nrf52 - working with Tuya/Smarthings:                                   
// application cluster
const cluster_t app_server_cluster_list[] ={
    DEF_CLUSTER_POWER_CLUSTER_ID( power_attr_list )
    DEF_CLUSTER_IAS_ZONE_CLUSTER_ID( ias_zone_attr_list )
};

Multi sensor SES code - nrf52 - not working with Tuya/Smarthings:
ZB_DECLARE_MULTI_SENSOR_CLUSTER_LIST(multi_sensor_clusters,
                                     basic_attr_list,
                                     identify_client_attr_list,
                                     identify_server_attr_list,
                                     temperature_attr_list,
                                     pressure_attr_list);


I really prefer to continue with Nordic SoC and SES, due to easy coding, detailed comments, as well as due to the time and investment put into development so far, but uncertainty/inability to work with major physical hub(s) is show stopper.

Thanks in advance

[Charlie]

Hi Igor,

Sorry for the late reply, Elfving is still on a business trip and I will try to help you with your concerns.

Unfortunately Nordic nrf52840DK loaded with multi_sensor firmware is showing as "Thing" in Smartthings Zigbee hub, and not showing at all in standard Zigbee hub in Tuya.
Till now I was able only to confirm that only "Light bulb" (ble_zigbee_dynamic_door_lock_nus) and "Door lock" (ble_zigbee_dynamic_door_lock_nus) examples do work both in Tuya and Smartthings.

As you have realised these compability issue only appears with multi_sensor example. The main reason is that this Zigbee Multi Sensor example added a custom cluster implemented for pressure in zb_zcl_pressure_measurement.h and zb_zcl_pressure_measurement.c.This cluster is not like temperature defined by the ZCL specification, so it will confuse other standered devices and cause different compibility issues if you add it to other Zigbee hubs.

If you read this article from FAQ: Zigbee Application Profiles, or why not all zigbee devices work with SmartThings - Wiki / FAQ - SmartThings Community, you would not be surprised that Zigbee world is quite devided. Some companies like IKEA and Philips Hue even close their Zigbee ecosystem only for their own product usage for different reasons. I have some personal advice for your smart home application development if you are still in the early stage.

1) You should consider the solutions with the following priority for your smart home development. Matter NCS>Zigbee NCS> Zigbee nRF5 SDK

2) Why Zigbee NCS> Zigbee nRF5 SDK? nRF5 SDK is currently in the maintenance stage now, you may hard to get support and have Zigbee certification compliance issues in the future. See nRF Connect SDK and nRF5 SDK statement to learn the reasons why you should switch to NCS in general. nRF Connect SDK have a production-level Zigbee solution that supports the latest Zigbee specification and complies with Zigbee product certification requirements.

3) Why Matter NCS>Zigbee NCS? The matter is a new smart home application layer protocol defined by Connectivity Standards Alliance(former Zigbee Alliance), it reused many technologies from Zigbee but added more features required by modern smart home applications like IP connection, more security and multi-smart home ecosystems supported and so on,  with similar HW requirements as Zigbee running on top of  IEEE 802.15.4 physical layer. It even defined Matter-Zigbee Hub to allow you to connect previous Zigbee devices. 

Best regards,

Charlie